Those build.xml changes enable driver autoloading by doing the
following: they scribble the names of our JDBC drivers inside derby.jar
and derbyclient.jar. The practical consequence of this change is that
both Derby JDBC drivers will be visible to DriverManager when you ask
for a Connection--before this change, DriverManager would only see the
specific driver for which your application issued a Class.forName().
I think (but I'm not sure) that the jdk's autoloading logic walks your
jar files in the order that they appear on the CLASSPATH. I also think
that DriverManager stops as soon as it finds a driver which claims to
understand the connection url. It is puzzling that the problem only
occurs when the db2jcc jar appears on the CLASSPATH. The db2jcc driver
name isn't scribbled inside that jar file so the autoloader shouldn't
see it.
-Rick
Olav Sandstaa wrote:
Rick Hillegas wrote:
DERBY-930 makes a couple changes. It would be interesting to see what
happens if you back out all of DERBY-930 and just apply its build.xml
changes. Those are the changes which trigger autoloading. This would
help us tease apart whether we have a vm bug or some regression
introduced by the other changes in DERBY-930.
I have backed out all changes done by DERBY-930 with the exception of
the changes done to the build.xml file. The problems in the Nist tests
still happens.
Regards,
Olav
