[
https://issues.apache.org/jira/browse/ARIES-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14906270#comment-14906270
]
John Ross commented on ARIES-1420:
----------------------------------
Please attach a test case with instructions on how to reproduce. At a minimum,
attach the composite subsystem and one bundle being installed into the parent
region that is not resolving.
With regard to "the BundleRevision associated to the subsystem", this is the
region context bundle. It's purpose is discussed in section 134.9 of the
specification. It does not export capabilities because it has none; therefore,
you do not see any when calling getCapabilities on that bundle. The wiring
would occur between the bundle requiring the capability and the bundle that
both contains and provides the capability. Sharing capabilities are discussed
in section 134.8 with a number of diagrams.
Using reflection to get a subsystem's capabilities should not be necessary. You
can use the Subsystem service instead. Subsystem service registrations and
their visibilities are discussed in section 134.13. All services are visible
from the root region. Services that are visible to a particular subsystem's
region are (1) the scoped subsystem of that region, (2) all unscoped subsystems
in that region, and (3) all children of subsystems in that region.
> OSGi capability handling does not seem to work between subsystems and OSGi
> bundles
> ----------------------------------------------------------------------------------
>
> Key: ARIES-1420
> URL: https://issues.apache.org/jira/browse/ARIES-1420
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
> Environment: LINUX, Equinox 3.8.2, Aries Subsystem 1.1.0
> Reporter: Madhav Bhargava
> Labels: OSGi-Capability, Provide-Capability
>
> Hello,
> We are using Aries subsystems container (1.1.0) to manage the lifecycle of
> subsystems in our Equinox OSGi runtime (3.8.2). Each of these subsystems
> provides certain capabilities which are declared in the SUBSYSTEM.MF file for
> the subsystem using standard OSGi Provide-Capability header. There are OSGi
> bundles in the runtime which are dynamically deployed to this runtime which
> have dependency on these subsystem capabilities which are declared via
> standard OSGi Require-Capability header.
> The problem is that the capabilities declared at the subsystem level is not
> registered in the BundleRevision associated to the subsystem which results in
> missing wiring between the provide and require capabilities. So even though
> the Subsystem with capabilities are active in the OSGi runtime the bundles
> which are depending on it do not go to RESOLVED state.
> On further investigation it appears that the only way to get the capabilities
> that are defined at the subsystem level is via reflection. We have tested
> this for feature and composite subsystems which are currently using.
> {code}
> final Method getCapabilitiesMethod =
> ReflectionUtils.findMethod(subsystem.getClass(), "getCapabilities",
> String.class);
> if (getCapabilitiesMethod != null) {
> final List<Capability> foundCapabilities =
> (List<Capability>) ReflectionUtils
> .invokeMethod(getCapabilitiesMethod,
> subsystem, capabilityNs);
> out.println("---------- Capabilities found
> ----------");
> out.println(foundCapabilities);
> } else {
> out.println("Could not locate method: getCapabilities
> via reflection for class " + s.getClass().getName());
> }
> {code}
> When we try and fetch the dependencies via BundleRevision then we do not get
> them:
> {code}
> final Bundle bundle =
> subsystem.getBundleContext().getBundle();
> final BundleRevision bundleRevision =
> bundle.adapt(BundleRevision.class);
> final List<Capability> bundleCapabilities =
> bundleRevision.getCapabilities("com.bingo.capability.adapter");
> out.println("---------- Capabilities found ----------");
> out.println(bundleCapabilities);
> {code}
> This IMO should not happen, any capability defined at a subsystem level
> should be available to be consumed outside its region to any bundle in the
> parent region. It seems that this is not the case when using the Aries
> subsystem container.
> Best Regards,
> Madhav
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
