db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suresh Thalamati (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1898) can not boot derby if class path contains 10.1 jars first and then 10.2 jars
Date Fri, 29 Sep 2006 00:13:50 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1898?page=comments#action_12438594 ] 
            
Suresh Thalamati commented on DERBY-1898:
-----------------------------------------

>>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.

Above idea to address the  problem  using new key name for crypto module will not work.  Even
if  a  new key is  used for crypto  module ,  we will be still attempting to load the new
class from the sealed 10.2 jar and fail. 




   



> 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.1.5, 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