FULL PRODUCT VERSION :
JDK
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b16)
Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows version 5.1 (Build 2600 xpsp_sp3_qfe130704-0421 Service Pack 3)
EXTRA RELEVANT SYSTEM CONFIGURATION :
Using JDK's Apache derby.jar
A DESCRIPTION OF THE PROBLEM :
Script library is placed in java.ext.dirs, such that that scripting language becomes available to all Java applications, including Oracle's JavaPlugin for browsers. As a result the classes of the script library get loaded via the extension class loader. Whenever a script (in ooRexx) is executed and accesses Java this is done via classes in the script library, which works thruout Java and all kind of use cases reliably.
Using Apache Derby as distributed via the JDK by placing it on the CLASSPATH and using java.sql.DriverManager to establish a connection does not work. The error message is:
java.sql.SQLException: No suitable driver found for jdbc:derby:derbyDB;create=true
The same program works, if either derby.jar is placed into java.ext.dirs, or the script library is placed on CLASSPATH, such that the class loader used for the script library classes can find derby.jar classes.
---
So the reason for the SQLException in this case seems to be that in the use case of the script library being in java.ext.dirs, but derby.jar on CLASSPATH, that DriverManager.getConnection() uses the extension class loader, as it is one of the script library classes that effectively carries out this invocation on behalf of the script (in C++, bridge via JNI).
Instead of throwing a SQLException at this point, DriverManager should try to load the driver via the thread's context class loader (in this use case the application class loader). Only, if that class loader does not find the driver, should the SQLException be thrown.
[The same must be the case when using boot strap classes, where the class loader reeturned is usually null.]
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Place a Java class that employs java.sql.DriverManager in java.ext.dirs, and put derby.jar on CLASSPATH. Run the Java class from the extension directory, it will not be able to find and load the driver.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
java.sql.DriverManager should find the derby.jar org.apache.derby.jdbc.EmbeddedDriver
ACTUAL -
java.sql.DriverManager throws a SQLException
ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.sql.SQLException: No suitable driver found for jdbc:derby:derbyDB;create=true
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Using org.apache.derby.jdbc.EmbeddedDataSource will work.
JDK
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b16)
Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows version 5.1 (Build 2600 xpsp_sp3_qfe130704-0421 Service Pack 3)
EXTRA RELEVANT SYSTEM CONFIGURATION :
Using JDK's Apache derby.jar
A DESCRIPTION OF THE PROBLEM :
Script library is placed in java.ext.dirs, such that that scripting language becomes available to all Java applications, including Oracle's JavaPlugin for browsers. As a result the classes of the script library get loaded via the extension class loader. Whenever a script (in ooRexx) is executed and accesses Java this is done via classes in the script library, which works thruout Java and all kind of use cases reliably.
Using Apache Derby as distributed via the JDK by placing it on the CLASSPATH and using java.sql.DriverManager to establish a connection does not work. The error message is:
java.sql.SQLException: No suitable driver found for jdbc:derby:derbyDB;create=true
The same program works, if either derby.jar is placed into java.ext.dirs, or the script library is placed on CLASSPATH, such that the class loader used for the script library classes can find derby.jar classes.
---
So the reason for the SQLException in this case seems to be that in the use case of the script library being in java.ext.dirs, but derby.jar on CLASSPATH, that DriverManager.getConnection() uses the extension class loader, as it is one of the script library classes that effectively carries out this invocation on behalf of the script (in C++, bridge via JNI).
Instead of throwing a SQLException at this point, DriverManager should try to load the driver via the thread's context class loader (in this use case the application class loader). Only, if that class loader does not find the driver, should the SQLException be thrown.
[The same must be the case when using boot strap classes, where the class loader reeturned is usually null.]
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Place a Java class that employs java.sql.DriverManager in java.ext.dirs, and put derby.jar on CLASSPATH. Run the Java class from the extension directory, it will not be able to find and load the driver.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
java.sql.DriverManager should find the derby.jar org.apache.derby.jdbc.EmbeddedDriver
ACTUAL -
java.sql.DriverManager throws a SQLException
ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.sql.SQLException: No suitable driver found for jdbc:derby:derbyDB;create=true
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Using org.apache.derby.jdbc.EmbeddedDataSource will work.