I'm not sure what the "synthesized bundle" you are talking about is. Subsystems run off resolver hooks.
The pattern for "global" extenders seems to be: - use the system bundle (bundle 0) to look for events of interest, so you see them for all bundles - have the extender register an extender capability - have bundles that need extension register a matching extender requirement - the extender should only extend bundles with no extender requirement or ones with extender requirements wired to their own extender capability. Then you can run multiple extenders of the same "kind" and each bundle needing extension should only get extended once. If you're sure there will only ever be one extender of this kind you can leave out the extender capabilites/requirements/matching. Generally once you have the bundle that needs extension, you want to use that bundle for everything the extender does, for instance access the service registry, config adimin, etc, so that the services, configs, etc, the extender uses are actually the ones visible to that bundle. thanks david jencks On Mar 6, 2015, at 5:13 AM, David Bosschaert <[email protected]> wrote: > Hi Manuel, > > There are really three possible situations if I'm not mistaken. > > 1. The extender is in the same subsystem as the extendee(s). In this > case things should just work as-is. > 2. The extender is in a parent subsystem of the extendees. In this > case there are two sub-situations: > 2a. If all the child subsystems are feature subsystems (no isolation) > things should still work as-is. > 2b. If any of the child subsystems has isolation (application / > composite subsystems) then something special needs to be done - the > extender needs to be 'subsystem-aware'. This means that it needs to > use the right bundle context to listen for bundle/service changes > (such as the framework bundle context) and it needs to register any > new services under the right bundle context so that the isolated child > subsystem can see them but not others. The synthesized bundle > associated with each isolated subsystem can be used for this. In the > case of 'global' service registrations (e.g. something like the > ConfigAdmin service) you most likely need separate instances or > facades for each isolated child subsystem, in order to not leak any > information from other isolated subsystem. > > I think that your case is the 2b case. The camel extender needs to be > made subsystem aware. What this means precisely is a little bit > different from case to case but I can think of the camel extender > using the bundle context associated with the subsystem that it's > running in to watch for bundle events. So if you're running in the > root subsystem, you use the framework bundle context. If you're > running in a child subsystem, you'd use its associated bundle context. > That way the camel extender will always see what's in child > subsystems, but not in any parent subsystem, which I guess is what you > really want. If the camel bundle registers OSGi services and/or other > global components then you need to think about limiting the visibility > for isolated subsystems... > > Cheers, > > David > > On 6 March 2015 at 09:34, Manuel Holzleitner > <[email protected]> wrote: >> Hello, >> >> I would like to understand how to use the subsystem in combination with >> extenders but I couldn't find any details on how to do it in the right way. >> >> Specifically, I have bundle in the root subsystem: >> org.apache.camel.camel-core which uses a bundle tracker (on its own bundle >> context) to extend camel component bundles (e.g. camel-ftp). I would like to >> separate the camel components along with their dependencies into isolated >> composite subsystems. >> >> When now starting a camel component subsystem the extender does not get >> notified with an event since they do not share the same scope. How can I >> make sure that the camel-core extender should be notified with such events? >> >> Is it enough to specify i.e. provide/require osgi.extender capabilities and >> also specify them on the subsystem level? May another possible solution is >> that the camel-core extender uses a bundle tracker on the system bundle, >> since this should be notified with the events in all subsystems. Is this >> correct? If yes, is this also the preferred way to do it? >> >> I have seen that in the blueprint extender there is a property >> ("org.apache.aries.blueprint.use.system.context") also to specify that the >> bundle tracker is using the system context. Was this property added for the >> same reason? >> >> I would appreciate any help, hints or pointers to detailed information on >> this issue (i.e. osgi spec section)? >> >> Kind Regards, >> Manuel
