I think that Aries registers it's custom Scope service for the root bundle somewhere reachable (I think on aries subsystem core). I'm not sure if there is a Scope registered on every scoped bundle. I'm even less sure what other subsystem implementations do.
I think it also registers a bunch of Repository services instances, but I don't recall on exactly what, and I'm not sure if what gets registered in the repository exactly matches the subsystem headers, since not all capabilities need be actually created. (Also, I am not sure why Subsystem has non-deprecated import/export service headers as well as Capabilities). BTW, there is precisely one ESA file listed in maven central. Simon P. S. I feel odd using the word "think" when replying to a "tjwat...@us.ibm.com" ( https://en.wikipedia.org/wiki/Think_%28IBM%29 ) On Thu, May 18, 2017, 9:57 AM Thomas Watson <tjwat...@us.ibm.com> wrote: > The easiest (and likely most performant way) to determine which scoped > subsystem a bundle belongs to is to iterate over the known scoped > subsystems and call: > > bundle == > subsystem.getBundleContext().getBundle(bundleToCheck.getBundleId(); > > If this is true then the 'bundle' belongs to the scoped 'subsystem'. This > works because scoped subsystems should not be able to 'see' bundles that > are installed outside of its own scope. The scoped subsystem's context > should only list bundles that are contained it its own scope so > getBundle(long id) will return null if the bundle is not in that subsystem. > > Tom > > > > > ----- Original message ----- > From: Cristiano Gavião <cvgav...@gmail.com> > Sent by: osgi-dev-boun...@mail.osgi.org > To: osgi-dev@mail.osgi.org > Cc: > Subject: Re: [osgi-dev] How to get the custom capabilities provided by a > scoped subsystem ? > > Date: Thu, May 18, 2017 8:29 AM > > > 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 <cvgav...@gmail.com> <cvgav...@gmail.com> > Sent by: osgi-dev-boun...@mail.osgi.org > To: osgi-dev@mail.osgi.org > 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 > hargr...@us.ibm.com > > > > ----- Original message ----- > From: Cristiano Gavião <cvgav...@gmail.com> <cvgav...@gmail.com> > Sent by: osgi-dev-boun...@mail.osgi.org > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > <osgi-dev@mail.osgi.org> > 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 > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
