I really think dragging in any awareness of subsystems is going to make things disastrously more complicated than they need to be. The upcoming R6 DS 1.3 spec mentions the approach I suggest of listening on the system bundle for DS implementations that want to work for bundles in isolated environments (such as subsystems). The extender capability/requirement/wiring bit is part of the spec. The (trunk, unreleased) Felix DS implementation has a configuration flag to choose whether to use its' own bundle or the system bundle for bundle tracking, and exposes an appropriate extender capability. bnd trunk now adds an extender requirement for bundles that end up using the 1.3 DS namespace (or you request it using an option). I don't think we implemented the "requires wiring" bit yet though.
thanks david jencks On Mar 6, 2015, at 10:40 AM, Manuel Holzleitner <[email protected]> wrote: > Hi, > > thanks for your information. I agree that case 2b should match in this case. > It's a very good point that the camel extender within an subsystem needs to > extend for the subsystem context and only in the root subsystem on the > framework context. But how should the camel-core extender find out in which > subsystem it resides? > > I sketched the following solution according to what you proposed: > ... > public void start(BundleContext context) throws Exception { > LOG.info("Camel activator starting"); > > BundleContext trackerContext = context; > ServiceReference serviceReference = > context.getServiceReference("org.osgi.service.subsystem.Subsystem"); > if (serviceReference != null) { > org.osgi.service.subsystem.Subsystem subsystem = > (org.osgi.service.subsystem.Subsystem) context.getService(serviceReference); > if (subsystem != null) { > LOG.debug("Camel activator starting in subsystem: {}", > subsystem); > > if > (subsystem.getSymbolicName().equals(org.osgi.service.subsystem.SubsystemConstants.ROOT_SUBSYSTEM_SYMBOLICNAME)) > { > trackerContext = > context.getBundle(Constants.SYSTEM_BUNDLE_LOCATION).getBundleContext(); > } else { > trackerContext = subsystem.getBundleContext(); > } > } > } > > tracker = new BundleTracker(trackerContext, Bundle.ACTIVE, this); > tracker.open(); > LOG.info("Camel activator started"); > } > ... > > I also needed to add an optional Import-Package to org.osgi.service.subsystem > package and a optional dependency to osgi.enterprise 5.0.0 so that this > mechanism is only active for containers with subsystem features. > First tests showed that the bundle tracker events are received properly in > the camel extender in the root subsystem also for subsystems. I would need to > further test this on different subsystem levels and check the service > registration for correct subsystem isolation. Do you think this should be the > right way to do it? > > The alternative proposal with the "global" extender pattern also sounds > interesting but now I'm wondering which of those options should be preferred. > Since you mentioned that this approach seems to be a common pattern could you > point me to an actual extender implementation that uses this approach? > > Thanks for your help! > Manuel > > On Fri, Mar 6, 2015 at 4:14 PM, David Bosschaert <[email protected]> > wrote: > Hi David > > On 6 March 2015 at 14:48, David Jencks <[email protected]> wrote: > > I'm not sure what the "synthesized bundle" you are talking about is. > > Subsystems run off resolver hooks. > > AFAIK synthesized bundles appear for every isolated subsystem. If you > want to see an example see bundle 20 in the following example: > http://coderthoughts.blogspot.com/2014/01/osgi-subsytems-on-apache-felix.html > > Best regards, > > David >
