[
https://issues.apache.org/jira/browse/FELIX-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Berger updated FELIX-969:
-----------------------------------
Attachment: Test_cases.zip
The bundles used in the Test cases (binary + source)
> system bundle does not correctly handle (export) package attributes
> -------------------------------------------------------------------
>
> Key: FELIX-969
> URL: https://issues.apache.org/jira/browse/FELIX-969
> 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
>
> Attachments: Test_cases.zip
>
>
> This issue is related to the follwing mailing list thread:
> http://www.mail-archive.com/us...@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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
