Derby
  1. Derby
  2. DERBY-2175

Derby plugin problem with webstart (packaging issue)

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 10.2.2.0
    • Fix Version/s: None
    • Component/s: Eclipse Plug-in
    • Environment:
      Java Webstart, Eclipse 3.3M3
    • Urgency:
      Normal

      Description

      There is a problem with the current packaging of the derby plugin that prevents
      derby classes from being found by the classloader when running an RCP
      application using java webstart.

      I rebuilt this plugin using a MANIFEST.MF that exports all the packages and
      specifies the classpath and it works.

      You can find my packaging here (SVN Web access)
      http://sharemedia.svn.sourceforge.net/viewvc/sharemedia/org.apache.derby.core/

      This problem is only a packaging issue, there is no need to do code changes.

      Scenario :
      1 - Create a new RCP product (plugin/feature/product)
      2 - Make the plugin depends on derby.core.
      3 - Add Class.forName( "org.apache.derby.jdbc.EmbeddedDriver").newInstance();
      in the code
      4 - Launch the product : I works.
      5 - Export the feature for webstart
      6 - Create a new feature for webstart, include & sign startup.jar, create the
      main jnlp, include the previous feature.
      7 - Export the 2nd feature for webstart
      8 - Launch the feature using the jnlp file. -> Class not found

      Cause :
      In the derby plugin, the packages are exported using the plugin.xml. This does
      not work with webstart.
      This can de fixed by adding a manifest.mf and exporting the derby packages in
      this file :

      Export-Package: org.apache.derby.authentication,
      org.apache.derby.catalog,
      org.apache.derby.catalog.types,
      org.apache.derby.client,
      org.apache.derby.client.am,
      org.apache.derby.client.net,
      org.apache.derby.client.resources,
      org.apache.derby.database,
      org.apache.derby.diag,
      org.apache.derby.drda,
      org.apache.derby.iapi.db,
      org.apache.derby.iapi.error,
      org.apache.derby.iapi.jdbc,
      org.apache.derby.iapi.reference,
      org.apache.derby.iapi.services.cache,
      org.apache.derby.iapi.services.classfile,
      org.apache.derby.iapi.services.compiler,
      org.apache.derby.iapi.services.context,
      org.apache.derby.iapi.services.crypto,
      org.apache.derby.iapi.services.daemon,
      org.apache.derby.iapi.services.i18n,
      org.apache.derby.iapi.services.info,
      org.apache.derby.iapi.services.io,
      org.apache.derby.iapi.services.loader,
      org.apache.derby.iapi.services.locks,
      org.apache.derby.iapi.services.monitor,
      org.apache.derby.iapi.services.property,
      org.apache.derby.iapi.services.stream,
      org.apache.derby.iapi.services.uuid,
      org.apache.derby.iapi.sql,
      org.apache.derby.iapi.sql.compile,
      org.apache.derby.iapi.sql.conn,
      org.apache.derby.iapi.sql.depend,
      org.apache.derby.iapi.sql.dictionary,
      org.apache.derby.iapi.sql.execute,
      org.apache.derby.iapi.store.access,
      org.apache.derby.iapi.store.access.conglomerate,
      org.apache.derby.iapi.store.access.xa,
      org.apache.derby.iapi.store.raw,
      org.apache.derby.iapi.store.raw.data,
      org.apache.derby.iapi.store.raw.log,
      org.apache.derby.iapi.store.raw.xact,
      org.apache.derby.iapi.tools.i18n,
      org.apache.derby.iapi.types,
      org.apache.derby.iapi.util,
      org.apache.derby.impl.db,
      org.apache.derby.impl.drda,
      org.apache.derby.impl.io,
      org.apache.derby.impl.jdbc,
      org.apache.derby.impl.jdbc.authentication,
      org.apache.derby.impl.load,
      org.apache.derby.impl.services.bytecode,
      org.apache.derby.impl.services.cache,
      org.apache.derby.impl.services.daemon,
      org.apache.derby.impl.services.jce,
      org.apache.derby.impl.services.locks,
      org.apache.derby.impl.services.monitor,
      org.apache.derby.impl.services.reflect,
      org.apache.derby.impl.services.stream,
      org.apache.derby.impl.services.uuid,
      org.apache.derby.impl.sql,
      org.apache.derby.impl.sql.catalog,
      org.apache.derby.impl.sql.compile,
      org.apache.derby.impl.sql.conn,
      org.apache.derby.impl.sql.depend,
      org.apache.derby.impl.sql.execute,
      org.apache.derby.impl.sql.execute.rts,
      org.apache.derby.impl.store.access,
      org.apache.derby.impl.store.access.btree,
      org.apache.derby.impl.store.access.btree.index,
      org.apache.derby.impl.store.access.conglomerate,
      org.apache.derby.impl.store.access.heap,
      org.apache.derby.impl.store.access.sort,
      org.apache.derby.impl.store.raw,
      org.apache.derby.impl.store.raw.data,
      org.apache.derby.impl.store.raw.log,
      org.apache.derby.impl.store.raw.xact,
      org.apache.derby.impl.tools.dblook,
      org.apache.derby.impl.tools.ij,
      org.apache.derby.impl.tools.sysinfo,
      org.apache.derby.io,
      org.apache.derby.jdbc,
      org.apache.derby.osgi,
      org.apache.derby.tools,
      org.apache.derby.vti
      Bundle-ClassPath: lib/derby.jar,
      lib/derbyclient.jar,
      lib/derbynet.jar,
      lib/derbytools.jar,

      Using the updated derby plugin, the product works.

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          Triaged for 10.5.2.

          Show
          Knut Anders Hatlen added a comment - Triaged for 10.5.2.
          Hide
          Nicolas Richeton added a comment -

          Yes, only the public api should be exported, sorry.

          I think the problem comes from the webstart classloader, which has strict security rules when it comes to jar and class visibility.

          Show
          Nicolas Richeton added a comment - Yes, only the public api should be exported, sorry. I think the problem comes from the webstart classloader, which has strict security rules when it comes to jar and class visibility.
          Hide
          Daniel John Debrunner added a comment -

          Would it work if the list of exported packages was limited to the packages in Derby's public api?
          This is the approach taken for derby.jar for its OSGi bundle manifest.

          As a further thought since Eclipse is OSGi based (I think) and derby.jar is an OSGI bundle should this just work without extra exports in the plugin manifest? Is the real problem that the other jars are not OSGi bundles?

          Show
          Daniel John Debrunner added a comment - Would it work if the list of exported packages was limited to the packages in Derby's public api? This is the approach taken for derby.jar for its OSGi bundle manifest. As a further thought since Eclipse is OSGi based (I think) and derby.jar is an OSGI bundle should this just work without extra exports in the plugin manifest? Is the real problem that the other jars are not OSGi bundles?

            People

            • Assignee:
              Unassigned
              Reporter:
              Nicolas Richeton
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development