db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: jdk16 and suite derbyall - 128 failures
Date Fri, 19 May 2006 23:19:01 GMT
Hi Olav,

Which driver (Network or Embedded) do you expect should be loaded? Also, 
what is your classpath when the test fails?

Thanks,
-Rick

]Olav Sandstaa wrote:

> I have not found the real cause for why the Nist tests fail but here is a
> short re-cap of my current findings - in case anyone else is looking 
> at this
> problem or know this code better than me and have suggestions on what 
> is wrong.
> 1. The security exception that makes the test fail (see earlier email) is
>   happening because the variable home in DirStorageFactory.doInit() which
>   should contain the path for the directory where the test should run 
> in null
>   (see also earlier email).
>
> 2. The "home" variable should be initialized to the correct value in
>   the constructor of the StorageFactoryService class. This contains the
>   following piece of code:
>
>       Object monitorEnv = Monitor.getMonitor().getEnvironment();
>       if (monitorEnv instanceof File) {
>           ....
>
>   Unfortunately the first of these two lines returns a null value 
> (instead
>   of a File object as it should) making the "home" variable not getting
>   initialized. (Comment: I think this code should be extended with
>   an "else" part to this if statement making Derby be more "fail fast" in
>   this situation? ).
>
>   So why do we not get a File object here? The answer to this question is
>   that I do not think the FileMonitor is created. And why is the 
> FileMonitor
>   not created?
>
> 3. If I understand the code correctly, the FileMonitor is created during
>   loading/booting of the JDBC driver. The EmbeddedDriver.java file 
> contains to methods that boots the driver:
>
>   a. Static code:
>
>       public class EmbeddedDriver implements Driver {
>
>    static {
>            System.out.println("EmbeddedDriver.static"); // by Olav
>        EmbeddedDriver.boot();
>    }
>
>   b. The constructor:
>
>        // Boot from the constructor as well to ensure that
>    // Class.forName(...).newInstance() reboots Derby
>    // after a shutdown inside the same JVM.
>    public EmbeddedDriver() {
>            System.out.println("EmbeddedDriver.EmbeddedDriver"); // by 
> Olav
>            EmbeddedDriver.boot();
>    }
>
>   Both these "boots" the JDBC driver and eventually calls the method
>   JDBCBoot.boot. This method contains the following code that should
>   get the monitors loaded:
>
>    public void boot(String protocol, PrintStream logging) {
>
>       if (org.apache.derby.jdbc.InternalDriver.activeDriver() == null)
>        {
>            // request that the InternalDriver (JDBC) service and the
>            // authentication service be started.
>            //
>            addProperty("derby.service.jdbc", 
> "org.apache.derby.jdbc.InternalDriver");
>            addProperty("derby.service.authentication", 
> AuthenticationService.MODULE);
>
>            Monitor.startMonitor(bootProperties, logging);
>
>
>   When the Nist tests fails, the part of this code that do
>   Monitor.startMonitor is not run (at least not as part of the Nist test
>   itself).
>
> That was probably more than I planned to say about the code. Then some
> observations:
>
> A. When the Nist test succeed (by backing out DERBY-930 or removing 
> the DB2
>   driver or ....) I see that:
>
>     a. The static method of the EmbeddedDriver is executed
>
>     b. org.apache.derby.jdbc.InternalDriver.activeDriver() returns null.
>
>     c. and the JDBCBoot.boot() methods starts the Monitors.
>
>     d. The EmbeddedDriver's constructor is run.
>
> B. When the Nist test fails I see:
>
>     a. The static method of the EmbeddedDriver is NOT executed (at least
>        not as part of the Nist test, but it could have been run earlier
>        by the framework?)
>
>     b. The EmbeddedDriver's constructor is run.
>
>     c. org.apache.derby.jdbc.InternalDriver.activeDriver() returns
>        NOT null (ie. it already have a driver)
>
>     d. The JDBCBoot.boot() does not starts the Monitors (due to c.)
>
>   It seems like we "some time earlier" in the VM's life (possible during
>   startup or run of one of the other suites?) that:
>
>    1. The static methdo of the EmbeddedDriver has been executed (or 
> MAYBE IT
>       IS NEVER executed?)
>
>    2. A driver has been loaded since InternalDriver.activeDriver() 
> returns
>       a driver (from where?)
>
>    3. The FileMonitor has not been started. Why not?
>
> A last observation is:
>
> C. The Nist suite is the only suite that has useprocess=false defined. If
>   I remove this from the property file it seems like the tests run ok.
>
> Any feedback on this, suggestions and questions are highly welcome - I 
> am on
> thin ice on this :-)
>
> Regards,
> Olav
>
>
>
> Olav Sandstaa wrote:
>
>> 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
>>
>>
>


Mime
View raw message