Hi Thomas thanks for the insights...
My initial idea was to track for scoped subsystems installation as a
whole based on its capabilities. After detecting one by a global
extender it would to create specific configurations (ConfigurationAdmin)
for components in their parent kernel subsystem. So each scoped
subsystem would import only those services for their contents to consume.
more bellow...
On 17/05/2017 10:23, Thomas Watson wrote:
In order to do that you would have to track capabilities by using the
system.bundle context in order to see capabilities being provided by
the individual bundles within the scoped subsystems being installed by
using something like a BundleTracker. Then you would have to figure
out which subsystem the bundle belonged to and determine which
capabilities that subsystem exports with its own sharing policy
headers (Provide-Capability, Export-Capability etc). I'm not sure
this makes any sense with your scenario.
I'm already doing something like this, but out of subsystem.
I thought doing that, but I was not able to determine which subsystem
the detected bundle belongs to. do you have ideas how to figure this out ?
For the extender pattern is far better to act upon the individual
bundles within the subsystem by looking at their
capabilities/requirements (or some other meta-data like DS component
XML) and using their BundleContext to get a properly scoped view of
the world according to the subsystem they are installed in. For
example, this is how a single blueprint or DS implementation can work
across all bundles contained in various scoped subsystems. They track
bundles using the system.bundle context, but they consume/register
services on behalf of the extendee bundle by using the extendee
bundle's context.
Tom
----- Original message -----
From: Cristiano Gavião <[email protected]>
Sent by: [email protected]
To: [email protected]
Cc:
Subject: Re: [osgi-dev] How to get the custom capabilities
provided by a scoped subsystem ?
Date: Wed, May 17, 2017 7:58 AM
Hummm... :-\
I was about to create a kind of extender provider tracking on the
subsystem capabilities... will need to rethink it then...
thanks BJ.
On 16/05/2017 22:09, BJ Hargrave wrote:
I doubt it. The region bundles don't provide or require the
capabilities themselves.
You will probably need to use the subsystem service to get the
subsystem manifest and parse the headers yourself.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
[email protected] <mailto:[email protected]>
----- Original message -----
From: Cristiano Gavião <[email protected]>
<mailto:[email protected]>
Sent by: [email protected]
<mailto:[email protected]>
To: OSGi Developer Mail List <[email protected]>
<mailto:[email protected]>
Cc:
Subject: [osgi-dev] How to get the custom capabilities
provided by a scoped subsystem ?
Date: Tue, May 16, 2017 4:46 PM
Hello OSGi experts,
In a subsystem manifest we can declare provided capabilities
using the
header "Provide-Capability:".
I'm trying to get them using the bundle context from the
subsystem
service (injected by DS):
> List<Capability> caps = pScopeSubsystem.getBundleContext()
> .getBundle().adapt(BundleRevision.class)
> .getCapabilities(null);
> for (Capability capability : caps) {
> System.out.println("Cap: " +
capability.toString());
> }
Also tried BundleWiring:
> BundleWiring bw =
pKernelSubsystem.getBundleContext().getBundle()
> .adapt(BundleWiring.class);
> List<BundleCapability> capabilities = bw.getCapabilities(null);
But the only capabilities that I was able to get are those:
> Cap: osgi.wiring.bundle; bundle-version:Version="1.0.0";
>
osgi.wiring.bundle="org.osgi.service.subsystem.region.context.1"
> Cap: osgi.wiring.host; bundle-version:Version="1.0.0";
> osgi.wiring.host="org.osgi.service.subsystem.region.context.1"
> Cap: osgi.identity;
> osgi.identity="org.osgi.service.subsystem.region.context.1";
> type="osgi.bundle"; version:Version="1.0.0"
So, what is the way to get the custom capabilities declared
for a scope
subsystem?
many thanks,
Cristiano
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected] <mailto:[email protected]>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
