You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Alexander Berger (JIRA)" <ji...@apache.org> on 2009/04/30 11:29:30 UTC
[jira] Reopened: (FELIX-969) system bundle does not correctly
handle (export) package attributes
[ https://issues.apache.org/jira/browse/FELIX-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Berger reopened FELIX-969:
------------------------------------
I reopen this issue as it is still not completely fixed. The test cases show
(see below) that imports using the "bundle-symblic-name" attribute still do not
work for packages that are added by extension bundles (fragment bundles
with extension:=framework).
I have created the following test scenario consisting of two bundles. The
first bundle (called the Provider bundle) looks like this:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Provider
Bundle-SymbolicName: Provider
Bundle-Version: 1.0.0
Export-Package: normal.export;provider=bundle
The second bundle (called the Fragment bundle) looks like this:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Fragment
Bundle-SymbolicName: Fragment
Bundle-Version: 1.0.0
Fragment-Host: system.bundle;extension:=framework
Export-Package: fragment.export;provider=
Then I created the following bundles to test each single scenario:
Case 1: Import using the bundle-symbolic-name attribute:
--------------------------------------------------------------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Case 1
Bundle-SymbolicName: Case.1
Bundle-Version: 1.0.0
Bundle-Activator: dummy.Activator
Import-Package: org.osgi.framework,
normal.export;bundle-symbolic-name="Provider";resolution:=optional,
fragment.export;bundle-symbolic-name="system.bundle";resolution:=optional
Result:
package resolved
----------------------------------
normal.export ok
fragment.export failed
Case 2: Import using the bundle-symbolic-name attribute 2:
--------------------------------------------------------------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Case 2
Bundle-SymbolicName: Case.2
Bundle-Version: 1.0.0
Bundle-Activator: dummy.Activator
Import-Package: org.osgi.framework,
normal.export;bundle-symbolic-name="Provider";resolution:=optional,
fragment.export;bundle-symbolic-name="org.apache.felix.framework";resolution:=optional
Result:
package resolved
----------------------------------
normal.export ok
fragment.export failed
Case 3: Import using the bundle-symbolic-name attribute 3:
--------------------------------------------------------------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Case 3
Bundle-SymbolicName: Case.3
Bundle-Version: 1.0.0
Bundle-Activator: dummy.Activator
Import-Package: org.osgi.framework,
normal.export;bundle-symbolic-name="Provider";resolution:=optional,
fragment.export;bundle-symbolic-name="Fragment";resolution:=optional
Result:
package resolved
----------------------------------
normal.export ok
fragment.export failed
Case 4: Import using custom attribute:
--------------------------------------------------------------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Case 4
Bundle-SymbolicName: Case.4
Bundle-Version: 1.0.0
Bundle-Activator: dummy.Activator
Import-Package: org.osgi.framework,
normal.export;provider="bundle";resolution:=optional,
fragment.export;provider="fragment";resolution:=optional
Result:
package resolved
----------------------------------
normal.export ok
fragment.export ok
Case 5: DynamicImport-Package using the bundle-symbolic-name attribute:
--------------------------------------------------------------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Case 5
Bundle-SymbolicName: Case.5
Bundle-Version: 1.0.0
Bundle-Activator: dummy.Activator
Import-Package: org.osgi.framework
DynamicImport-Package: normal.export;bundle-symbolic-name="Provider",
fragment.export;bundle-symbolic-name="system.bundle"
Result:
package resolved
----------------------------------
normal.export ok
fragment.export failed
Case 6: DynamicImport-Package using the bundle-symbolic-name attribute 2:
--------------------------------------------------------------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Case 6
Bundle-SymbolicName: Case.6
Bundle-Version: 1.0.0
Bundle-Activator: dummy.Activator
Import-Package: org.osgi.framework
DynamicImport-Package: normal.export;bundle-symbolic-name="Provider",
fragment.export;bundle-symbolic-name="org.apache.felix.framework"
Result:
package resolved
----------------------------------
normal.export ok
fragment.export failed
Case 7: DynamicImport-Package using custome attribute:
--------------------------------------------------------------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Case 7
Bundle-SymbolicName: Case.7
Bundle-Version: 1.0.0
Bundle-Activator: dummy.Activator
Import-Package: org.osgi.framework
DynamicImport-Package: normal.export;provider="bundle",
fragment.export;provider="fragment"
Result:
package resolved
----------------------------------
normal.export ok
fragment.export ok
> 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/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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.