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

        Suresh Thalamati created issue -
        Andrew McIntyre made changes -
        Field Original Value New Value
        Fix Version/s 10.2.1.5 [ 11187 ]
        Suresh Thalamati made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Invalid [ 6 ]
        Andrew McIntyre made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Gavin made changes -
        Workflow jira [ 12385792 ] Default workflow, editable Closed status [ 12798518 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development