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
