db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: jdk16 and suite derbyall - 128 failures
Date Wed, 24 May 2006 14:23:09 GMT
Olav Sandstaa wrote:
> 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.
> 
[snipped - good investigation work]

> 
> 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).

I'm a little lost as to what you are describing here. What do you mean
when you say "attempts to boot an embedded Derby"? Loading the embedded
driver will always loaded the emebdded derby engine, unless it's already
booted. That's the function of the driver.

Then why does the driver boot fail? No properties are required to boot
the derby engine so maybe the auto-loading is broken in some way?

> 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.

What does the "at least kind of" mean? Either the driver is booted and
the engine running, or it isn't.

> 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.
>            //
>            addProperty("derby.service.jdbc",
> "org.apache.derby.jdbc.InternalDriver");
>            addProperty("derby.service.authentication",
> AuthenticationService.MODULE);
>            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).

Loading the driver is separate from creating databases so again I'm
confused as to what you are describing here. Does the nist suite or some
 part of the test harness set some properties that are only used at boot
time to create a database? Which properties are these?

Seems like we are close to solving this with your work, but maybe
missing some information still.

Thanks,
Dan.


Mime
View raw message