The AccessControlException thrown in DirStorageFactory.doInit() is caused
by the "home" (directory) variable having the value null.
As pointed out by Ole, the Nist tests started to fail in revision
r396638 (see DERBY-930). I have run derbyall for r396637 and r396638
with and without the DB2 driver in the path and printed the values of
the home and dataDirectory variables used by
DirStorageFactory.doInit():
without DB2 driver with DB2 driver
----------------------------------------------------------------------------
r396637: home: /export/home/tmp/derbysuite/nist home:
/export/home/tmp/derbysuite/nist
dataDirectory: wombat dataDirectory: wombat
r396638: home: /export/home/tmp/derbysuite/nist home: null
dataDirectory: wombat dataDirectory: wombat
So basically the Nist tests fail due to not knowing which directory to
create the database in.
..olav
Olav Sandstaa wrote:
The exception causing the Nist tests to fail when running derbyall
using jdk1.6 has the following call stack:
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)
I am working on to figure out why this happens when running with
jdk1.6 opposed to when running with earlier jdk versions. Since I am
not very familiar with the security manager configuration used by the
tests I appreciate all suggestions that other might have on why this
happens.
Regards,
Olav
