CLONE -system bundle does not correctly handle (export) package attributes
--------------------------------------------------------------------------
Key: FELIX-1123
URL: https://issues.apache.org/jira/browse/FELIX-1123
Project: Felix
Issue Type: Bug
Components: Framework, Specification compliance
Affects Versions: felix-1.4.1
Environment: 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
Reporter: Alexander Berger
Assignee: Richard S. Hall
Fix For: felix-1.6.0
This issue is related to the follwing mailing list thread:
http://www.mail-archive.com/[email protected]/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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
