db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olav Sandstaa <Olav.Sands...@Sun.COM>
Subject Re: jdk16 and suite derbyall - 128 failures
Date Tue, 23 May 2006 13:53:06 GMT
Hi Rick,

Rick Hillegas wrote:
> Hi Olav,
>
> Which driver (Network or Embedded) do you expect should be loaded? 
The test it asking for the following driver:

   org.apache.derby.jdbc.EmbeddedDriver

to be loaded.

> Also, what is your classpath when the test fails?
The class path is:

/home/os136802/derby/develop/trunk/jars/sane/derby.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyclient.jar:/home/os136802/derby/develop/trunk/jars/sane/derbytools.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyne
t.jar:/usr/local/share/java/db2jcc/lib/db2jcc.jar:/usr/local/share/java/db2jcc/lib/db2jcc_license_c.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyTesting.jar:/home/os136802/derby/develop/trunk/tools/java/junit.jar:/home/os136802/der
by/develop/trunk/tools/java/jakarta-oro-2.0.8.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyLocale_de_DE.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyLocale_es.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyLocale_fr
.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyLocale_it.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyLocale_ja_JP.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyLocale_ko_KR.jar:/home/os136802/derby/develop/trunk/ja
rs/sane/derbyLocale_pt_BR.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyLocale_zh_CN.jar:/home/os136802/derby/develop/trunk/jars/sane/derbyLocale_zh_TW.jar

Regards,
Olav


> 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