You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Suresh Thalamati (JIRA)" <de...@db.apache.org> on 2006/09/29 00:35:52 UTC
[jira] Created: (DERBY-1898) can not boot derby if class path
contains 10.1 jars first and then 10.2 jars
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
[jira] Commented: (DERBY-1898) can not boot derby if class path
contains 10.1 jars first and then 10.2 jars
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Resolved: (DERBY-1898) can not boot derby if class path
contains 10.1 jars first and then 10.2 jars
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1898?page=all ]
Suresh Thalamati resolved DERBY-1898.
-------------------------------------
Resolution: Invalid
Derby is not expected to work correctly, if two versions of derby jar files are present in the classpath.
> 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.6, 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
[jira] Updated: (DERBY-1898) can not boot derby if class path
contains 10.1 jars first and then 10.2 jars
Posted by "Andrew McIntyre (JIRA)" <de...@db.apache.org>.
[ 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
Re: [jira] Commented: (DERBY-1898) can not boot derby if class
path contains 10.1 jars first and then 10.2 jars
Posted by Suresh Thalamati <su...@gmail.com>.
Daniel John Debrunner (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-1898?page=comments#action_12438595 ]
>
> Daniel John Debrunner commented on DERBY-1898:
> ----------------------------------------------
>
> Is this expected to be supported?
I guess not, users are unlikely to mix up jars like me :-). I will
close the bug as Invalid. I ran into this issue with a class not
found error , when I was trying to add some encryption test cases to
the upgrade test, because upgrade test includes 10.2 classes(to get
the test class from 10.2 code line) ,with the old jars when creating
class loader for 10.1, but I guess that is a different problem.
Thanks
-suresh
[jira] Commented: (DERBY-1898) can not boot derby if class path
contains 10.1 jars first and then 10.2 jars
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1898?page=comments#action_12438595 ]
Daniel John Debrunner commented on DERBY-1898:
----------------------------------------------
Is this expected to be supported?
> 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