You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2009/05/05 22:13:36 UTC
[jira] Created: (FELIX-1123) CLONE -system bundle does not
correctly handle (export) package attributes
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/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.
[jira] Commented: (FELIX-1123) CLONE -system bundle does not
correctly handle (export) package attributes
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706184#action_12706184 ]
Richard S. Hall commented on FELIX-1123:
----------------------------------------
Refer to FELIX-969 for a test case showing a failure.
> 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.6.0
> 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.8.0
>
>
> 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.
[jira] Updated: (FELIX-1123) System bundle does still not correctly
handle (export) package attributes
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1123:
-----------------------------------
Summary: System bundle does still not correctly handle (export) package attributes (was: [CLONED] System bundle does not correctly handle (export) package attributes)
> System bundle does still 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.6.0
> 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-2.0.0
>
>
> 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.
[jira] Updated: (FELIX-1123) CLONE -system bundle does not
correctly handle (export) package attributes
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1123:
-----------------------------------
Affects Version/s: (was: felix-1.4.1)
felix-1.6.0
Fix Version/s: (was: felix-1.6.0)
felix-1.8.0
> 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/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.
[jira] Updated: (FELIX-1123) [CLONED] System bundle does not
correctly handle (export) package attributes
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1123:
-----------------------------------
Summary: [CLONED] System bundle does not correctly handle (export) package attributes (was: CLONE -system bundle does not correctly handle (export) package attributes)
> [CLONED] 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.6.0
> 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-2.0.0
>
>
> 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.
[jira] Updated: (FELIX-1123) CLONE -system bundle does not
correctly handle (export) package attributes
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1123:
-----------------------------------
Affects Version/s: (was: felix-1.6.0)
felix-1.4.1
Fix Version/s: (was: felix-1.8.0)
felix-1.6.0
> 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/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.
[jira] Resolved: (FELIX-1123) [CLONED] System bundle does not
correctly handle (export) package attributes
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall resolved FELIX-1123.
------------------------------------
Resolution: Fixed
I just committed a patch to trunk that now correctly assigns BSN/BV to extension bundle exports when attached to the system bundle. My own tests verified it was working. Please confirm and close if satisfied. Thanks.
> [CLONED] 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.6.0
> 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-2.0.0
>
>
> 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.
[jira] Updated: (FELIX-1123) CLONE -system bundle does not
correctly handle (export) package attributes
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1123:
-----------------------------------
Affects Version/s: (was: felix-1.4.1)
felix-1.6.0
Fix Version/s: (was: felix-1.6.0)
felix-1.8.0
> 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.6.0
> 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.8.0
>
>
> 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.
[jira] Updated: (FELIX-1123) CLONE -system bundle does not
correctly handle (export) package attributes
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1123:
-----------------------------------
Fix Version/s: (was: felix-1.8.0)
felix-2.0.0
> 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.6.0
> 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-2.0.0
>
>
> 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.