I am not convinced that this is a VM bug yet. Since the Nist tests run
without this problem by either excluding the DB2 driver from the path or
by backing out DERBY-930 I still think it is something in the test
framework that is causing the problem.
I think the security exception occurs due to a bug we have an "illegal"
(not complete) file name for the directory name. I have not figured out
yet why the variable containing the path is null. I am working my way
through the code to find where the null value first shows up. There are
some other indications that this is a consequence of some other error
that occurs earlier in the test start up. (I will post more info when I
figure it out, but that has to wait until tomorrow.)
Olav
David Van Couvering wrote:
Looks like a VM bug -- I wonder if their attempt to get the user.dir
property in java.io.UnixFileSystem.resolve is likely not encapsulated
in a PrivilegedAction block.
Olav - why would a null value for "user.dir" cause a security exception?
David
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
