Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 1362 invoked from network); 18 May 2006 17:49:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 May 2006 17:49:57 -0000 Received: (qmail 77332 invoked by uid 500); 18 May 2006 17:49:40 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 77269 invoked by uid 500); 18 May 2006 17:49:40 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 77239 invoked by uid 99); 18 May 2006 17:49:40 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 May 2006 10:49:40 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [192.18.42.249] (HELO nwkea-pix-1.sun.com) (192.18.42.249) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 May 2006 10:49:38 -0700 Received: from d1-sfbay-02.sun.com ([192.18.39.112]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4IHnIba019854 for ; Thu, 18 May 2006 10:49:18 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-02.sun.com by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZH005012PYE700@d1-sfbay-02.sun.com> (original mail from David.Vancouvering@Sun.COM) for derby-dev@db.apache.org; Thu, 18 May 2006 10:49:18 -0700 (PDT) Received: from [192.168.1.100] ([64.142.91.3]) by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZH00KLS2U5Y610@d1-sfbay-02.sun.com> for derby-dev@db.apache.org; Thu, 18 May 2006 10:49:18 -0700 (PDT) Date: Thu, 18 May 2006 10:49:28 -0700 From: David Van Couvering Subject: Re: jdk16 and suite derbyall - 128 failures In-reply-to: <446C62DE.7020207@sun.com> Sender: David.Vancouvering@Sun.COM To: derby-dev@db.apache.org Message-id: <446CB3A8.3020209@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <836ae9af0605101709w12a02835n7aabf25b95e5c8bd@mail.gmail.com> <446297B2.7080009@sun.com> <446C27DF.4030603@sun.com> <446C62DE.7020207@sun.com> User-Agent: Thunderbird 1.5.0.2 (X11/20060427) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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.(EmbedConnection.java:216) > at > org.apache.derby.impl.jdbc.EmbedConnection30.(EmbedConnection30.java:72) > > at > org.apache.derby.impl.jdbc.EmbedConnection40.(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.(utilMain.java:176) > at org.apache.derby.impl.tools.ij.utilMain14.(utilMain14.java:51) > at org.apache.derby.impl.tools.ij.Main14.getutilMain(Main14.java:102) > at org.apache.derby.impl.tools.ij.Main.(Main.java:265) > at org.apache.derby.impl.tools.ij.Main14.(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