Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
framework-1.4.1
-
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
Attachments
Issue Links
- is cloned by
-
FELIX-1123 System bundle does still not correctly handle (export) package attributes
- Resolved