Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <1405063911.1241554776796.JavaMail.jira@brutus>
Date: Tue, 5 May 2009 13:19:36 -0700 (PDT)
From: "Richard S. Hall (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Closed: (FELIX-969) system bundle does not correctly handle
 (export) package attributes
In-Reply-To: <1953593674.1236154796056.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/FELIX-969?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard S. Hall closed FELIX-969.
---------------------------------

    Resolution: Fixed

We are tracking this on FELIX-1123 for a future Felix release.

> 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 definiti=
on
>   with the following attributes:
>     =E2=80=A2 bundle-symbolic-name - The bundle symbolic name of the expo=
rting
>       bundle. In the case of a Fragment bundle, this is the host bundle's=
 symbolic
>       name.
>     =E2=80=A2 bundle-version - The bundle version of the exporting bundle=
. In the case
>       of a Fragment bundle, this is the host bundle's version.
>      =20
> And section 3.6.5 specifies how these attributes must be applied when res=
olving
> packages.
> Using Apache Felix Version 1.4.1 I have encountered the following behavio=
ur=20
> when using different approaches to import packages exported by the system=
 bundle
> (org.apache.felix.framework respectively system.bundle) when using attrib=
ute
> matching:
> For the following test cases the bundle manifest of the system bundle loo=
ks like
> this:
>   Bundle-Version =3D 1.4.1
>   Bundle-Name =3D System Bundle
>   Bundle-SymbolicName =3D org.apache.felix.framework
>   Export-Package =3D my.package; provider=3D"xxx", ...
> Test Case 1:
>    Import-Package: my.package;bundle-symbolic-name=3D"system.bundle"
>  Result: Package my.package could not be resolved!
> =20
> =20
> Test Case 2:
>    Import-Package: my.package;bundle-symbolic-name=3D"org.apache.felix.fr=
amework"
>  Result: Package my.package could not be resolved!
> =20
> =20
> Test Case 3:
>    Import-Package: my.package;provider=3D"xxx"
>  Result: Package my.package was resolved successfully.
> =20
> =20
> Test Case 4:
>    DynamicImport-Package: *;bundle-symbolic-name=3D"system.bundle"
>  Result: Package my.package could not be resolved (class not found at run=
time)!
> =20
> =20
> Test Case 2:
>    DynamicImport-Package: *;bundle-symbolic-name=3D"org.apache.felix.fram=
ework"
>  Result: Package my.package could not be resolved (class not found at run=
time)!
> =20
> =20
> Test Case 3:
>    DynamicImport-Package: my.package;provider=3D"xxx"
>  Result: Package my.package was resolved successfully (at runtime).
> The same behaviour is also true for packages that are added to the list o=
f=20
> exported packages of the system bundle by extension bundles (fragment bun=
dles=20
> with extension:=3Dframework). For such packages another problem arises as=
 the=20
> matching attributes as defined in the Export-Package header of the extens=
ion=20
> bundle are not taken over by the system bundle. So for example if the ext=
ension
> bundle has the following export:
>    Export-Package my.package;provider=3D"xxx";version=3D"1.0.0"
> Then the system bundle seems to discard the attribute "provider" but resp=
ects the
> version attribute:
>    Export-Package my.package;version=3D"1.0.0"
> So it looks as if the framework should be fixed to always add the automat=
ic attributes to=20
> 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.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.