Derby
  1. Derby
  2. DERBY-1898

can not boot derby if class path contains 10.1 jars first and then 10.2 jars

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 10.2.1.6, 10.2.2.0
    • Fix Version/s: 10.2.2.0
    • Component/s: None
    • Labels:
      None
    • Environment:

      Description

      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

        Activity

        Hide
        Suresh Thalamati added a comment -

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

        Show
        Suresh Thalamati added a comment - >>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.
        Hide
        Daniel John Debrunner added a comment -

        Is this expected to be supported?

        Show
        Daniel John Debrunner added a comment - Is this expected to be supported?
        Hide
        Andrew McIntyre added a comment -

        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.

        Show
        Andrew McIntyre added a comment - 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.
        Hide
        Suresh Thalamati added a comment -

        Derby is not expected to work correctly, if two versions of derby jar files are present in the classpath.

        Show
        Suresh Thalamati added a comment - Derby is not expected to work correctly, if two versions of derby jar files are present in the classpath.
        Hide
        Andrew McIntyre added a comment -

        This issue has been resolved for over a year with no further movement. Closing.

        Show
        Andrew McIntyre added a comment - This issue has been resolved for over a year with no further movement. Closing.

          People

          • Assignee:
            Unassigned
            Reporter:
            Suresh Thalamati
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development