[
https://issues.apache.org/jira/browse/FELIX-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756405#comment-13756405
]
Timothy Ward commented on FELIX-4212:
-------------------------------------
Hi Richard,
Thanks for locating the relevant part of the spec. The R4.3 JavaDoc for
BundleWiring.getCapabilities() doesn't mention the resolver (hence my
confusion) The wording is as follows:
-------------
java.util.List<BundleCapability> getCapabilities(java.lang.String namespace)
Returns the capabilities provided by this bundle wiring.
A capability may not be required by any bundle wiring and thus there may be no
wires for the capability.
A bundle wiring for a non-fragment revision provides a subset of the declared
capabilities from the bundle revision and all attached fragment revisions. Not
all declared capabilities may be provided since some may be discarded. For
example, if a package is declared to be exported and import, only one is
selected and the other is discarded.
Parameters:
namespace - The name space of the capabilities to return or null to return the
capabilities from all name spaces.
Returns:
A list containing a snapshot of the BundleCapabilitys, or an empty list if this
bundle wiring provides no capabilities in the specified name space. If this
bundle wiring is not in use, null will be returned. For a given name space, the
list contains the wires in the order the capabilities were specified in the
manifests of the bundle revision and the attached fragments of this bundle
wiring. There is no ordering defined between capabilities in different name
spaces.
--------------------------
This was updated in R5 to:
---------------------------
java.util.List<BundleCapability> getCapabilities(java.lang.String namespace)
Returns the capabilities provided by this bundle wiring.
Only capabilities considered by the resolver are returned. For example,
capabilities with effective directive not equal to resolve are not returned.
A capability may not be required by any bundle wiring and thus there may be no
wires for the capability.
A bundle wiring for a non-fragment revision provides a subset of the declared
capabilities from the bundle revision and all attached fragment revisions†. Not
all declared capabilities may be provided since some may be discarded. For
example, if a package is declared to be both exported and imported, only one is
selected and the other is discarded.
A bundle wiring for a fragment revision with a symbolic name must provide
exactly one identity capability.
† The identity capability provided by attached fragment revisions must not be
included in the capabilities of the host bundle wiring.
Parameters:
namespace - The namespace of the capabilities to return or null to return the
capabilities from all namespaces.
Returns:
A list containing a snapshot of the BundleCapabilitys, or an empty list if this
bundle wiring provides no capabilities in the specified namespace. If this
bundle wiring is not in use, null will be returned. For a given namespace, the
list contains the wires in the order the capabilities were specified in the
manifests of the bundle revision and the attached fragments† of this bundle
wiring. There is no ordering defined between capabilities in different
namespaces.
------------------------
I've put in a quick test. My bundle manifest contains:
------
Provide-Capability: test.namespace, test.namespace; effective:=active
Require-Capability: test.namespace; filter:="(foo=bar)"; resolution:=optional,
test.namespace; filter:="(foo=bar)"; effective:=active
------
and I see the following:
Felix 4.2.1:
------------
Bundle Revision
test.namespace effective null
test.namespace effective active
test.namespace effective null
test.namespace effective active
Bundle Wiring
test.namespace effective null
Felix 4.2.0:
------------
Bundle Revision
test.namespace effective null
test.namespace effective active
test.namespace effective null
test.namespace effective active
Bundle Wiring
test.namespace effective null
Felix 4.0.3:
------------
Bundle Revision
test.namespace effective null
test.namespace effective active
test.namespace effective null
test.namespace effective active
Bundle Wiring
test.namespace effective null
Equinox 3.8.2:
--------------
Bundle Revision
test.namespace effective null
test.namespace effective active
test.namespace effective null
test.namespace effective active
Bundle Wiring
test.namespace effective null
Equinox 3.7.2:
--------------
Bundle Revision
test.namespace effective null
test.namespace effective null
Bundle Wiring
test.namespace effective null
Looks like I should raise a bug against Equinox 3.7.x ...
> Felix framework doesn't provide access to Generic Requirements and
> Capabilities with effective:=active
> ------------------------------------------------------------------------------------------------------
>
> Key: FELIX-4212
> URL: https://issues.apache.org/jira/browse/FELIX-4212
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.2.1
> Reporter: Timothy Ward
> Priority: Critical
>
> I am trying to access Require-Capability and Provide-Capability metadata from
> my bundle's manifest using the BundleWiring API. Most capabilities show up
> fine, but none of the ones with effective:=active are present. I understand
> that these capabilities are ignored by the resolver, and may not have any
> wirings, but I expect them to show up anyway. This avoids me having to
> provide my own parsing code to turn the manifest entries into Requirements
> and Capabilities.
> Having checked with the OSGi Core Platform Expert group, active time
> requirements and capabilities really should be showing up in the
> BundleWiring. My guess is that this will be easy to fix!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
