Derby
  1. Derby
  2. DERBY-1945

Need changes to manifest for OSGi environment

    Details

    • Urgency:
      Normal

      Description

      When running with Derby in an OSGi environment, there are a couple of changes that are needed in the manifest.

      1. The manifest does not have a Bundle Symbolic Name. This causes some tools not to recognize it as an OSGi bundle and some things don't work nicely without the symbolic name.
      Add Bundle-SymbolicName: derby to the manifest.

      2. I'm working with a product that creates dynamic proxies for all of the interfaces like Connection, Statement, etc.
      As part of doing that, it needs access to all classes that are referenced in those interface classes.
      There are several classes that are referenced in packages that are not exported. The following exports needed to be added to the manifest:
      org.apache.derby.iapi.jdbc
      org.apache.derby.impl.jdbc

        Issue Links

          Activity

          Hide
          Niclas Hedhman added a comment -

          1. Agree, Bundle-SymbolicName and Bundle-Version are required by the OSGi R4 spec, and forms a unique key.

          2. I disagree. If you are adding such internal behavior to the bundle, you should probably either add them inside the Derby bundle, or create a Fragment that attaches itself to the host bundle (Derby). This allows you to access the internal classes accordingly. Internal packages should not be exported frivolously.

          Show
          Niclas Hedhman added a comment - 1. Agree, Bundle-SymbolicName and Bundle-Version are required by the OSGi R4 spec, and forms a unique key. 2. I disagree. If you are adding such internal behavior to the bundle, you should probably either add them inside the Derby bundle, or create a Fragment that attaches itself to the host bundle (Derby). This allows you to access the internal classes accordingly. Internal packages should not be exported frivolously.
          Hide
          Stephen Felts added a comment -

          Regarding #2, the problem is that the exposed interfaces references classes that are not exported. Either they should be exported or the references should be removed.

          Show
          Stephen Felts added a comment - Regarding #2, the problem is that the exposed interfaces references classes that are not exported. Either they should be exported or the references should be removed.
          Hide
          Daniel John Debrunner added a comment -

          Which exposed interfaces reference classes that are not exported?

          Good to have details on the issues you are seeing so others can understand the problem.

          Show
          Daniel John Debrunner added a comment - Which exposed interfaces reference classes that are not exported? Good to have details on the issues you are seeing so others can understand the problem.
          Hide
          Stephen Felts added a comment -

          The bundle, as it stands, has a number of packages that are exported in the manifest.
          For example, org.apache.derby.jdbc is exported. That means that I can reference any classes in this package in an OSGi environment. If only a subset of classes in that package should be exposed, there is syntax supported by OSGi to expose only specific classes (or the other classes should be moved out of the package). When I reference any of those classes, all of the packages for which there is an import statement must also be exported. Otherwise, a ClassNotFound will occur at runtime. It's not worth adding any OSGi information to the manifest if the jar is not usable as an OSGi bundle.

          The two packages that I referenced in the original description were packages that I needed to add to the manifest exports when running a program in an OSGi environment that covers most if not all of the JDBC interface.

          However, looking at imports from org.apache.derby.jdbc, it would seem that the following are needed for all of the classes in org.apache.derby.jdbc:
          org.apache.derby.iapi.db
          org.apache.derby.iapi.error
          org.apache.derby.iapi.jdbc
          org.apache.derby.iapi.services.context
          org.apache.derby.iapi.services.i18n
          org.apache.derby.iapi.services.info
          org.apache.derby.iapi.services.io
          org.apache.derby.iapi.services.monitor
          org.apache.derby.iapi.sql
          org.apache.derby.iapi.sql.conn
          org.apache.derby.iapi.store.access
          org.apache.derby.iapi.store.access.xa
          org.apache.derby.impl.jdbc

          Working with OSGi gives one a new vision on code isolation, modularity, etc.

          Show
          Stephen Felts added a comment - The bundle, as it stands, has a number of packages that are exported in the manifest. For example, org.apache.derby.jdbc is exported. That means that I can reference any classes in this package in an OSGi environment. If only a subset of classes in that package should be exposed, there is syntax supported by OSGi to expose only specific classes (or the other classes should be moved out of the package). When I reference any of those classes, all of the packages for which there is an import statement must also be exported. Otherwise, a ClassNotFound will occur at runtime. It's not worth adding any OSGi information to the manifest if the jar is not usable as an OSGi bundle. The two packages that I referenced in the original description were packages that I needed to add to the manifest exports when running a program in an OSGi environment that covers most if not all of the JDBC interface. However, looking at imports from org.apache.derby.jdbc, it would seem that the following are needed for all of the classes in org.apache.derby.jdbc: org.apache.derby.iapi.db org.apache.derby.iapi.error org.apache.derby.iapi.jdbc org.apache.derby.iapi.services.context org.apache.derby.iapi.services.i18n org.apache.derby.iapi.services.info org.apache.derby.iapi.services.io org.apache.derby.iapi.services.monitor org.apache.derby.iapi.sql org.apache.derby.iapi.sql.conn org.apache.derby.iapi.store.access org.apache.derby.iapi.store.access.xa org.apache.derby.impl.jdbc Working with OSGi gives one a new vision on code isolation, modularity, etc.
          Hide
          Stephen Felts added a comment -

          Sorry - that last long list is not correct. Obviously these packages are all resolved because they are in the jar itself.

          The proxy generation needs to generate classes that call the methods within the exposed classes. That means that all return values and parameters need to be exposed.
          That explains why I only saw the two packages needed instead of the dozen.
          Since the proxy generation is automatic and not exposed, it would take some work to figure out exactly what parameters/return values are in the two listed packages.

          Show
          Stephen Felts added a comment - Sorry - that last long list is not correct. Obviously these packages are all resolved because they are in the jar itself. The proxy generation needs to generate classes that call the methods within the exposed classes. That means that all return values and parameters need to be exposed. That explains why I only saw the two packages needed instead of the dozen. Since the proxy generation is automatic and not exposed, it would take some work to figure out exactly what parameters/return values are in the two listed packages.
          Hide
          Daniel John Debrunner added a comment -

          Which exposed class or classes causes the proxy generation process problems?

          I think maybe the problem is, as you pointed out, that too many classes are being exposed in the org.apache.derby.jdbc package.

          The javadoc lists the api classes in that package, which is a sub-set of the public classes in the packge.

          I'm also wondering what the proxy generator is doing for connections returned by Derby's DataSources or Driver.
          Is it creating a proxy for java.sql.Connection or a Derby specific class? Because the api indicates that connections
          returned by derby are java.sql.Connection objects, the implementation class is not meant to be assumed or used by applications.

          Show
          Daniel John Debrunner added a comment - Which exposed class or classes causes the proxy generation process problems? I think maybe the problem is, as you pointed out, that too many classes are being exposed in the org.apache.derby.jdbc package. The javadoc lists the api classes in that package, which is a sub-set of the public classes in the packge. I'm also wondering what the proxy generator is doing for connections returned by Derby's DataSources or Driver. Is it creating a proxy for java.sql.Connection or a Derby specific class? Because the api indicates that connections returned by derby are java.sql.Connection objects, the implementation class is not meant to be assumed or used by applications.
          Hide
          Bradley Beddoes added a comment - - edited

          The symbolic name component of this issue would appear to still not be fixed in 10.4.1.3 making it impossible to use as an OSGi bundle straight out of the box (Effects at least derby.jar) even though the associated issue claims it is fixed.

          Could this be looked at?

          Show
          Bradley Beddoes added a comment - - edited The symbolic name component of this issue would appear to still not be fixed in 10.4.1.3 making it impossible to use as an OSGi bundle straight out of the box (Effects at least derby.jar) even though the associated issue claims it is fixed. Could this be looked at?
          Hide
          Stan Bradbury added a comment -

          We too would like to be able to use derby in an OSGI 4 compliant bundle but /META-INF/MANIFEST.MF is missing Bundle-SymbolicName. This JIRA addresses the Bundle-SymbolicName topic but also makes another requests ( two issues in one). Should another entry or a sub-task be created for item #1 such that it might be addressed independently of the issue of adding classes to the exports in the manifest?

          ISSUE of interest:
          The manifest does not have a Bundle Symbolic Name. This causes some tools not to recognize it as an OSGi bundle and some things don't work nicely without the symbolic name.
          Add Bundle-SymbolicName: derby to the manifest.

          Show
          Stan Bradbury added a comment - We too would like to be able to use derby in an OSGI 4 compliant bundle but /META-INF/MANIFEST.MF is missing Bundle-SymbolicName. This JIRA addresses the Bundle-SymbolicName topic but also makes another requests ( two issues in one). Should another entry or a sub-task be created for item #1 such that it might be addressed independently of the issue of adding classes to the exports in the manifest? ISSUE of interest: The manifest does not have a Bundle Symbolic Name. This causes some tools not to recognize it as an OSGi bundle and some things don't work nicely without the symbolic name. Add Bundle-SymbolicName: derby to the manifest.
          Hide
          Myrna van Lunteren added a comment -

          I think that's wise, this issue as a whole has stalled because there's controversy. I think adding the Bundle Symbolic Name is not so controversial.

          Show
          Myrna van Lunteren added a comment - I think that's wise, this issue as a whole has stalled because there's controversy. I think adding the Bundle Symbolic Name is not so controversial.
          Hide
          Bryan Pendleton added a comment -

          Bundle-SymbolicName was added to the manifest by DERBY-3730, so perhaps we can mark this issue as fixed?

          Show
          Bryan Pendleton added a comment - Bundle-SymbolicName was added to the manifest by DERBY-3730 , so perhaps we can mark this issue as fixed?
          Hide
          Bryan Pendleton added a comment -

          It seems like the primary issue here was the Bundle-SymbolicName, and that
          was taken care of in DERBY-3730, so I'm resolving this as a duplicate of
          DERBY-3730.

          Show
          Bryan Pendleton added a comment - It seems like the primary issue here was the Bundle-SymbolicName, and that was taken care of in DERBY-3730 , so I'm resolving this as a duplicate of DERBY-3730 .

            People

            • Assignee:
              Bryan Pendleton
              Reporter:
              Stephen Felts
            • Votes:
              2 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development