Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 18 May 2006 12:01:55 -0700
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: jdk16 and suite derbyall - 128 failures
In-reply-to: <446CB3A8.3020209@sun.com>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <446CC4A3.7000906@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> <446CB3A8.3020209@sun.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

396638 enabled driver autoloading (DERBY-930). It's the patch which 
required us to migrate to Mustang build 81--that build fixes a bug which 
short-circuited autoloading from jar files under a SecurityManager. With 
DERBY-930 in place, the vm will execute its autoloading logic when 
running against jar files. Without DERBY-930, autoloading will not be 
triggered.  Have you tried running against an older Mustang build with 
DERBY-930 in place?

DERBY-930 makes a couple changes. It would be interesting to see what 
happens if you back out all of DERBY-930 and just apply its build.xml 
changes. Those are the changes which trigger autoloading. This would 
help us tease apart whether we have a vm bug or some regression 
introduced by the other changes in DERBY-930.

Regards,
-Rick

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
>