TeamSuperGood demonstrated all the great functionalities of Impresario. We kicked butt and we looked good doing it (in our team shirts)! We had lots of people interested in the project. Many SOEN 390 students have shown interest in extending the project and we are also developing our own plan on what functionalities we would like to add. A fellow TeamSuperGoodmate is working on making a demo available online, so stay tuned for that!

I’d like to take this opportunity to thank those who helped us with the project through their various contributions and insight: Candy, Mustafa and Dr. Constantinides.

(This includes the person I talked to on Friday about the XMLUtil. If you’re reading this, please give me your email again because the one I have does not work. Thanks.)

//Prepare the statement
PreparedStatement statement = prepareStatement(query, variables, values);

//Strip out the object information
String statementString = statement.toString();
statementString = statementString.substring(statementString.indexOf('-')+1);

//Original query execution
//return statement.executeQuery();

return statement.executeQuery(statementString);

Just as some notes, prepareStatement() takes the query and binds all the values to the string. The next line gets the value of the PreparedStatement as a string. This will yield something similar to this:

com.mysql.jdbc.ServerPreparedStatement[3] - call impr_linkable_object_find_connected_by_type(2, ‘org.impresario.core’, ‘user’, ‘org.impresario.core’, ‘project’)

As you can see, there is information about the object before you get the sql. The following line strips everything before that first - so that you are left with only the sql call itself which is then executed independently as a string.

Suddenly, we no longer have that annoying problem popping up.

Ok, so I select the list of projects, then I select a specific project.

Ok, so only one person is in that project, nice, I click on him and look at his list of projects.

huh? They don’t match!

So Soen390 has Ka Lun as a Manager, Ka Lun shows that he is the a Contribute on Soen490, So why doesn’t he know about his Soen390?

My Bad, I introduced that bug by through some of the test code I inserted while debugging another bug. (Lower level code has funky higher level consequences)

Summary:
* To create a certificate:
keytool -genkey -alias myKeyAlias -keypass myKeypassword -keystore mykeystoreFileName.bin -storepass publicKeykeystorePassword

* To sign the applet (it has to be a .jar file):
jarsigner -keystore mykeystoreFileName.bin MyApplet.jar myKeyAlias

* To verify if the applet is correctly signed:
jarsigner -verify MyApplet.jar

PREPAREDSTATEMENTS!!!!

If you use a preparedStatement in java so you can use placeholders and whatnot, do not retrieve binary data. If you would like to see this in action just follow the following code. The first run will show you the data being retrieved mutated, then, instead of getting rs from the prepared statement, uncomment the commented out line and get it from an executequery method on a specific string. Voila Everything works! So basically, if you would like to retrieve binary data, do not create the prepared statment and then run it as this will not work.

public static void main2(String[] args) throws Exception {

	Connection db = DbRegistry.getDbConnection();
	Statement stmt = db.createStatement();
	stmt.executeUpdate("DROP TABLE IF EXISTS bytesTest;");
	stmt.executeUpdate("CREATE TABLE bytesTest(field1 blob)");

	byte counter = Byte.MIN_VALUE;
		
	byte[] allBytesOriginal = new byte[256];
		
	for (int i = 0; i < 256; i++) {
		allBytesOriginal[i] = counter++;
	}

	PreparedStatement pStmt = db.prepareStatement("INSERT INTO bytesTest VALUES (?)");
	pStmt.setBytes(1, allBytesOriginal);
	pStmt.executeUpdate();

	pStmt = db.prepareStatement("SELECT SUBSTRING(field1,1, ?) FROM bytesTest");		
	pStmt.setInt(1,300);
	ResultSet rs= pStmt.executeQuery();
		
//    ResultSet rs = stmt.executeQuery("SELECT SUBSTRING(field1,1, 300) FROM bytesTest");

	rs.next();

	byte[] retrBytes = rs.getBytes(1);

	if (retrBytes.length != allBytesOriginal.length) {
		System.out.println("Bytes not same length");
		System.exit(1);
	}

	for (int i = 0; i < retrBytes.length; i++) {
		if (retrBytes[i] != allBytesOriginal[i]) {
			System.out.println("Bytes differed at position " + i
					+ ", retrieved "
					+ Integer.toHexString(retrBytes[i] & 0xff) + " , sent "
					+ Integer.toHexString(allBytesOriginal[i] & 0xff));
		}
	}
		
	Blob asBlob = rs.getBlob(1);
	byte[] blobBytes = asBlob.getBytes(1, 256);
	
	if (blobBytes.length != allBytesOriginal.length) {
		System.out.println("Bytes not same length");
		System.exit(1);
	}
	
	for (int i = 0; i < blobBytes.length; i++) {
		if (blobBytes[i] != allBytesOriginal[i]) {
			System.out.println("Bytes differed at position " + i
				+ ", retrieved "
				+ Integer.toHexString(blobBytes[i] & 0xff) + " , sent "
				+ Integer.toHexString(allBytesOriginal[i] & 0xff));
		}
	}
}

A quick workaround that I devised was this following blurp of code: (This works if you have the same version of prepared statements as I do and the - seperates the blurp from toString() from the executable SQL statement.) You may need to edit it yourself and customize to you preparedstatement.

In the following code:
selectStatement is a preparedStatement that has all its placeholders set and is ready for execution.
execQuery is a String that you build to extract the actual sql statement from the selectStatement.toString()

String execQuery= selectStatement.toString();
				
ResultSet rs= selectStatement.executeQuery(execQuery.substring(execQuery.indexOf("-")+2));

The bug raised at MySQL can be found here:
http://bugs.mysql.com/15735

Eric, notice the red. I think its an awesome color… much more punch then the blue I had going on before!