db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Olav Sandstaa (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading
Date Tue, 06 Jun 2006 12:34:57 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1379?page=comments#action_12414951 ] 

Olav Sandstaa commented on DERBY-1379:
--------------------------------------


Updating this jira with the main findings from the email discussions
covering this issue. The complete discussion can be found here:

http://www.nabble.com/jdk16-and-suite-derbyall---128-failures-t1596754.html


The call stack for security exception that causes the Nist tests to fail:

java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir
read)
   at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
   at java.security.AccessController.checkPermission(AccessController.java:546)
   at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
   at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
   at java.lang.System.getProperty(System.java:652)
   at java.io.UnixFileSystem.resolve(UnixFileSystem.java:118)
   at java.io.File.getCanonicalPath(File.java:559)
   at org.apache.derby.impl.io.DirStorageFactory.doInit(DirStorageFactory.java:190)
   at org.apache.derby.impl.io.BaseStorageFactory.init(BaseStorageFactory.java:87)
   at org.apache.derby.impl.services.monitor.StorageFactoryService.privGetStorageFactoryInstance(StorageFactoryService.java:201)
   at org.apache.derby.impl.services.monitor.StorageFactoryService.access$400(StorageFactoryService.java:64)
   at org.apache.derby.impl.services.monitor.StorageFactoryService$11.run(StorageFactoryService.java:774)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.apache.derby.impl.services.monitor.StorageFactoryService.getCanonicalServiceName(StorageFactoryService.java:768)
   at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1537)
   at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:990)
   at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:541)
   at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1591)
   at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:216)
   at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:72)
   at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(EmbedConnection40.java:47)
   at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:64)
   at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:200)
   at java.sql.DriverManager.getConnection(DriverManager.java:548)
   at java.sql.DriverManager.getConnection(DriverManager.java:148)
   at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:516)
   at org.apache.derby.impl.tools.ij.util.startJBMS(util.java:616)
   at org.apache.derby.impl.tools.ij.ConnectionEnv.init(ConnectionEnv.java:64)
   at org.apache.derby.impl.tools.ij.utilMain.<init>(utilMain.java:176)
   at org.apache.derby.impl.tools.ij.utilMain14.<init>(utilMain14.java:51)
   at org.apache.derby.impl.tools.ij.Main14.getutilMain(Main14.java:102)
   at org.apache.derby.impl.tools.ij.Main.<init>(Main.java:265)
   at org.apache.derby.impl.tools.ij.Main14.<init>(Main14.java:68)
   at org.apache.derby.impl.tools.ij.Main14.getMain(Main14.java:91)
   at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:189)
   at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
   at org.apache.derby.tools.ij.main(ij.java:60)
   at org.apache.derbyTesting.functionTests.harness.RunIJ.run(Unknown Source)
   at java.lang.Thread.run(Thread.java:619)


The cause for the Nist test to fail when running with jdk16 is the
introduction of autoloading of the embedded driver combined with the
value that derby.system.home has at the time the embedded driver is
loaded. 

When the Nist tests succeeds, derby.system.home contains the name of
the directory where the test should be run
(e.g. /export/home/tmp/derbysuite/nist in my case). derby.system.home
is set by the test harness when it starts each individual test suite.

When the Nist tests fails the embedded driver and the Derby engine is
loaded as part of startup of derbyall. This happens as part of loading
the DB2 driver in the following code in RunList.shouldSkipTest:

    if (framework.equals("DerbyNet"))
    {
       // skip if the derbynet.jar is not in the Classpath
       try {
           Class.forName("org.apache.derby.drda.NetworkServerControl");
       } 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 {
           Class.forName("com.ibm.db2.jcc.DB2Driver");
       } 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 boots
the Derby engine. Unfortunately, at this time the derby.system.home
property is not set. This leads to the following happening
during autoloading of the embedded Driver:

  * The FileMonitor's home variable gets the value null based on reading derby.system.home.

When the Nist tests start an hour later and request to a database to
be created, the initialization of the StorageFactory fails with the
security exception since it uses the FileMonitor's home variable
(which is null) as the directory of where to create the
database. Without the security manager this would have succeeded, but
with the security manager, a security exception is raised when trying
to get the canonical path from the file system when only having the
name of the database directory (i.e. just having "wombat" instead of
"/export/....../wombat").

So basically the Nist tests fail due to the embedded driver is loaded
before derby.system.home is set to the value that it should have for
the tests, which again leads to the security exception when the VM
trying to get the canonical path name for the current directory.


> NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading
> -----------------------------------------------------------------------
>
>          Key: DERBY-1379
>          URL: http://issues.apache.org/jira/browse/DERBY-1379
>      Project: Derby
>         Type: Bug

>   Components: Tools
>     Versions: 10.2.0.0
>  Environment: Sun JDK 1.6
>     Reporter: Olav Sandstaa
>     Priority: Minor

>
> When running derbyall on jdk16 the Nist tests fails with the following exception:
>   java.security.AccessControlException: access denied
>   (java.util.PropertyPermission user.dir read)
> The tests started to fail after autoloading of JDBC drivers was added to the embedded
driver (see DERBY-930). 
> To reproduce the problem you need (a) to run from jar files (not class files) and (b)
have the DB2 driver in the class path.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message