db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olav Sandstaa <Olav.Sands...@Sun.COM>
Subject Re: jdk16 and suite derbyall - 128 failures
Date Wed, 24 May 2006 10:23:17 GMT
I think I have found what causes the Nist tests to fail when running
derbyall with jdk16. The Nist tests started to fail after DERBY-930
(Add support for autoloading of Derby client drivers) was check in.

Earlier the embedded driver was loaded into the jvm when the first of
the tests in the nist suite started and requested the Embedded driver
to be loaded explicitly (note that the Nist suite is the only suite
that run with useprocess=false).  Due to autoloading the embedded
driver may now be loaded at an earlier time in the test than before,
and that happens in certain situations (you run the test from jars,
you have the DB2 driver in path, the nist test is run with
useprocess=false). What happens is that during startup of derbyall the
following code in RunList.shouldSkipTest is executed:

     if (framework.equals("DerbyNet"))
        // skip if the derbynet.jar is not in the Classpath
        try {
        } catch (ClassNotFoundException cnfe) {
            driverNotFound = true;
            result = true;

        // skip if the IBM Universal JDBC Driver is not in the Classpath
        // note that that driver loads some javax.naming.* classes which 
may not
        // be present at runtime, and thus we need to catch a possible 
error too
        try {
        } catch (ClassNotFoundException cnfe) {
            driverNotFound = true;
            result = true;
        } catch (NoClassDefFoundError err) {
            driverNotFound = true;
            result = true;

When the Class.forName("com.ibm.db2.jcc.DB2Driver") is executed (and
the DB2 driver is actually in the class path) it seems to call some
methods that happens to be defined by any JDBC driver (see also the
comment in the code). The class loader seems to touch derby.jar to try
to find these methods, and this makes the embedded driver to
"automagically" be loaded. And loading the embedded driver also
"automagically" attempts to boot an embedded Derby. Unfortunately (or
fortunately?) at this time the Derby properties has not been set for
defining an embedded Derby and the booting of Derby fails (silently).
As a result the VM has the embedded driver loaded (at least kind of),
but no embedded database. At this point it is no problem for derbyall
since the first tests to run has useprocess=true.

About an hour or two later when the first Nist test starts it also
requests the embedded driver to be loaded into the same VM. In the
code for loading the driver and booting the database the following
check is done (see JDBCBoot.boot()):

     if (org.apache.derby.jdbc.InternalDriver.activeDriver() == null)
            // request that the InternalDriver (JDBC) service and the
            // authentication service be started.
            Monitor.startMonitor(bootProperties, logging);

The test for checking if the driver has been loaded returns a pointer
to the embedded driver loaded during starting of derbyall. Based on
this no Derby database is created (since it based on having the
embedded driver expect that it also must have an embedded
database). So the Nist tests are run with the embedded driver but no
embedded database. No surprise that this make the tests fail
eventually (with an security exception seen by the test).


View raw message