[ 
https://issues.apache.org/jira/browse/ARIES-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Ross closed ARIES-1420.
----------------------------
    Resolution: Cannot Reproduce

Closing this as "cannot reproduce". If you are able to provide a test case or 
detailed instructions for how to reproduce the issue, feel free to reopen it.

Please note that the latest release is 2.0.2. You may wish to try and reproduce 
the issue there as any fix would be applied to trunk which is currently at 
2.0.3-SNAPSHOT.

> 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)

Reply via email to