db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: jdk16 and suite derbyall - 128 failures
Date Fri, 19 May 2006 14:44:38 GMT
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.


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

View raw message