db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1898) can not boot derby if class path contains 10.1 jars first and then 10.2 jars
Date Sat, 30 Sep 2006 06:39:19 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1898?page=all ]

Andrew McIntyre updated DERBY-1898:
-----------------------------------

    Fix Version/s:     (was: 10.2.1.5)

I think this just needs to be closed as Invalid, since I don't think we would expect 10.1
and 10.2 jars to work when present on the same classpath. Taking 10.2.1.5 off of the FIx In
version to remove it from the 10.2.1.5 JIRA open issues report.

> can not boot derby   if class path contains   10.1  jars  first and then 10.2 jars
> ----------------------------------------------------------------------------------
>
>                 Key: DERBY-1898
>                 URL: http://issues.apache.org/jira/browse/DERBY-1898
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.2.1.5, 10.2.2.0
>         Environment: $ echo $CLASSPATH
> c:/suresht/jars_10_1//derby.jar;c:/suresht/jars_10_1//derbytools.jar;c:/suresht/
> jars_10_1//derbyclient.jar;c:/suresht/jars_10_1//derbynet.jar;c:/suresht/jars_10
> _1//derbyTesting.jar;c:/suresht/jars_10_1//jakarta-oro-2.0.8.jar;c:/suresht/jars
> _10_1//derbyLocale_de_DE.jar;c:/suresht/jars_10_1//derbyLocale_es.jar;c:/suresht
> /jars_10_1//derbyLocale_fr.jar;c:/suresht/jars_10_1//derbyLocale_it.jar;c:/sures
> ht/jars_10_1//derbyLocale_ja_JP.jar;c:/suresht/jars_10_1//derbyLocale_ko_KR.jar;
> c:/suresht/jars_10_1//derbyLocale_pt_BR.jar;c:/suresht/jars_10_1//derbyLocale_zh
> _CN.jar;c:/suresht/jars_10_1//derbyLocale_zh_TW.jar;c:/suresht/jars_10_1//junit.
> jar;C:/suresht/jars_10_2/derby.jar
> $
>            Reporter: Suresh Thalamati
>             Fix For: 10.2.2.0
>
>
> java -Dij.exceptionTrace=true -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij
> Exception in thread "main" java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.apache.derby.impl.tools.ij.util.loadDriver(Unknown Source)
>         at org.apache.derby.impl.tools.ij.util.loadDriverIfKnown(Unknown Source)
>         at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source)
>         at org.apache.derby.impl.tools.ij.util.startJBMS(Unknown Source)
>         at org.apache.derby.impl.tools.ij.ConnectionEnv.init(Unknown Source)
>         at org.apache.derby.impl.tools.ij.utilMain.<init>(Unknown Source)
>         at org.apache.derby.impl.tools.ij.utilMain14.<init>(Unknown Source)
>         at org.apache.derby.impl.tools.ij.Main14.getutilMain(Unknown Source)
>         at org.apache.derby.impl.tools.ij.Main.<init>(Unknown Source)
>         at org.apache.derby.impl.tools.ij.Main14.<init>(Unknown Source)
>         at org.apache.derby.impl.tools.ij.Main14.getMain(Unknown Source)
>         at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
>         at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
>         at org.apache.derby.tools.ij.main(Unknown Source)
> Caused by: java.lang.SecurityException: sealing violation: package org.apache.de
> rby.iapi.services.crypto is sealed
>         at java.net.URLClassLoader.defineClass(URLClassLoader.java:226)
>         at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.apache.derby.impl.services.monitor.BaseMonitor.getImplementations
> (Unknown Source)
>         at org.apache.derby.impl.services.monitor.BaseMonitor.getDefaultImplemen
> tations(Unknown Source)
>         at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unkno
> wn Source)
>         at org.apache.derby.impl.services.monitor.FileMonitor.<init>(Unknown Sou
> rce)
>         at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown S
> ource)
>         at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source)
>         at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source)
>         at org.apache.derby.jdbc.EmbeddedDriver.<clinit>(Unknown Source)
>         ... 16 more
> $
> ----
>  I think the problem is   in 10.2 ,,   cryptograph modules entries  were updated  with
a new  factory. 
> the new one is :
> derby.module.cryptographyJ2=org.apache.derby.impl.services.jce.JCECipherFactoryBuilder
> and the old one in 10.1  was
> derby.module.cryptographyJ2=org.apache.derby.impl.services.jce.JCECipherFactory
> --
>  My understanding was only one  modules.properties get loaded.  So updating  the above
property should not cause any issues.  But that assuption  seems to be wrong ,   for some
reason ,  monitor grabs all the modules.properties and loads them.  I just have no clue ,
 why we do that ?   (any one know why we do that ? )  .   
> I this  test case scenario,  I  think   all  the classes are refferring to the ones 10.1
, except the    cryptography module ,   becuase the property got  updated with the one with
10.2.  
> By doing a quick look at the code ,  , comments in code seems to indicate  duplicates
are ignored m but I think that code has a bug :
> BaseMonitor.java :
> Properties getDefaultModuleProperties()
> ..
>                             if( moduleList.contains( key))
>                                 // RESOLVE how do we localize messages before we have
finished initialization?
>                                 report( "Ignored duplicate property " + key + " in "
+ modulesPropertiesURL.toString());
>                             else
>                                 moduleList.setProperty( key, otherList.getProperty( key));
> ---
> I think the check for the duplicate should have been:   moduleList.containsKey(key) ,
instead of  moduleList.contains( key).   
> But  fixing the above one won't solve the existing problem with old jars,   I think 
the fix  for this issues is to use the different name for the  crypto module. 
> Thanks
> /suresh
>  
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message