Uploaded image for project: 'Felix'
  1. Felix
  2. FELIX-969

System bundle does not correctly handle (export) package attributes

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • framework-1.4.1
    • framework-1.6.0
    • None
    • java version "1.6.0_07"
      Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
      Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)
      SunOS castor 5.10 Generic_137111-08 sun4u sparc SUNW,Sun-Fire-V890

    Description

      This issue is related to the follwing mailing list thread:
      http://www.mail-archive.com/users@felix.apache.org/msg03403.html

      Section 3.5.5 of the OSGi core specification (4.1) states:

      The Framework will automatically associate each package export definition
      with the following attributes:

      • bundle-symbolic-name - The bundle symbolic name of the exporting
      bundle. In the case of a Fragment bundle, this is the host bundle's symbolic
      name.
      • bundle-version - The bundle version of the exporting bundle. In the case
      of a Fragment bundle, this is the host bundle's version.

      And section 3.6.5 specifies how these attributes must be applied when resolving
      packages.

      Using Apache Felix Version 1.4.1 I have encountered the following behaviour
      when using different approaches to import packages exported by the system bundle
      (org.apache.felix.framework respectively system.bundle) when using attribute
      matching:

      For the following test cases the bundle manifest of the system bundle looks like
      this:

      Bundle-Version = 1.4.1
      Bundle-Name = System Bundle
      Bundle-SymbolicName = org.apache.felix.framework
      Export-Package = my.package; provider="xxx", ...

      Test Case 1:

      Import-Package: my.package;bundle-symbolic-name="system.bundle"

      Result: Package my.package could not be resolved!

      Test Case 2:

      Import-Package: my.package;bundle-symbolic-name="org.apache.felix.framework"

      Result: Package my.package could not be resolved!

      Test Case 3:

      Import-Package: my.package;provider="xxx"

      Result: Package my.package was resolved successfully.

      Test Case 4:

      DynamicImport-Package: *;bundle-symbolic-name="system.bundle"

      Result: Package my.package could not be resolved (class not found at runtime)!

      Test Case 2:

      DynamicImport-Package: *;bundle-symbolic-name="org.apache.felix.framework"

      Result: Package my.package could not be resolved (class not found at runtime)!

      Test Case 3:

      DynamicImport-Package: my.package;provider="xxx"

      Result: Package my.package was resolved successfully (at runtime).

      The same behaviour is also true for packages that are added to the list of
      exported packages of the system bundle by extension bundles (fragment bundles
      with extension:=framework). For such packages another problem arises as the
      matching attributes as defined in the Export-Package header of the extension
      bundle are not taken over by the system bundle. So for example if the extension
      bundle has the following export:

      Export-Package my.package;provider="xxx";version="1.0.0"

      Then the system bundle seems to discard the attribute "provider" but respects the
      version attribute:

      Export-Package my.package;version="1.0.0"

      So it looks as if the framework should be fixed to always add the automatic attributes to
      exported packages (as defined in 3.5.5). Furthermore it should also make sure that all
      other (non automatic) attributes are respected especially for exorts that are added by
      extension bundles.

      Attachments

        1. Test_cases.zip
          12 kB
          Alexander Berger

        Issue Links

          Activity

            People

              rickhall Richard S. Hall
              alexberger Alexander Berger
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: