I don't have a strong opinion on whether to add such a wiring constraint in the aries blueprint implementation. Most likely the next blueprint spec revision will include such a constraint. Until the format is set by the spec you run the risk of introducing something incompatible. I suppose you could use the org.apache.aries namespace but that won't help with conflicts with the eclipse implementation. I'd probably wait until it was specced.
My opinion on whether the default scope should be isolated or global is highly prejudiced by my belief that using blueprint is a mistake :-) I therefore tend to think that if you insist on using it you should put the blueprint implementation in the isolated place your blueprint app is and that the default-isolated flag is better. If I thought blueprint was the best thing since sliced bread I'd probably think the global default was better. thanks david jencks On Mar 18, 2015, at 4:11 AM, Manuel Holzleitner <[email protected]> wrote: > Do you think that the same "requires wiring" functionality should also be > included in the Aries blueprint extender? The blueprint extender already > provides a property to listen for bundle changes on the system bundle, but > this property is disabled by default. Shouldn't that be changed to be enabled > per default so that blueprint is always subsystem aware? I would assume that > there is no difference between creating the bundle tracker on the system > bundle or the extender bundle for containers that do not use the subsystem > module. > > Kind Regards, > Manuel > > On Tue, Mar 10, 2015 at 3:05 PM, David Jencks <[email protected]> wrote: > That's pretty much the same code as I just wrote for DS :-) > > The only difference I see is that I used the BundleVersion rather than the > bundle id for comparison of "wired to the same bundle". It's unlikely but > perhaps conceivable that the extender itself might be present in two versions > perhaps during an upgrade. Anyway I used > > m_bundle.adapt(BundleRevision.class).equals(wire.getProvider()) > > which probably should factor out the adapt so it only happens once :-) > > thanks!! > david jencks > > On Mar 10, 2015, at 9:54 AM, Manuel Holzleitner > <[email protected]> wrote: > >> With your help, I tried to quickly implement this approach according to your >> suggestions for the camel-core example (see source snippet below) and tested >> it in combination with the subsystem module and correct >> require/provide-capabilities headers. Maybe you could briefly look over the >> extenderCapabilityWired() method to check whether this is how the "requires >> wiring" part should be implemented or if there is an easier or better way to >> do it. >> >> In general, I prefer this second option since also no (optional) dependency >> to the subsystem API needs to be established by the extender (in this case >> camel-core) and it seems to be aligned to the OSGi spec, as well. >> >> .... >> public void start(BundleContext context) throws Exception { >> LOG.info("Camel activator starting"); >> >> bundleId = context.getBundle().getBundleId(); >> tracker = new >> BundleTracker(context.getBundle(Constants.SYSTEM_BUNDLE_LOCATION).getBundleContext(), >> Bundle.ACTIVE, this); >> tracker.open(); >> >> LOG.info("Camel activator started"); >> } >> >> public void stop(BundleContext context) throws Exception { >> LOG.info("Camel activator stopping"); >> tracker.close(); >> LOG.info("Camel activator stopped"); >> } >> >> public Object addingBundle(Bundle bundle, BundleEvent event) { >> LOG.debug("Bundle started: {}", bundle.getSymbolicName()); >> >> if (extenderCapabilityWired(bundle)) { >> List<BaseService> r = new ArrayList<BaseService>(); >> registerComponents(bundle, r); >> registerLanguages(bundle, r); >> registerDataFormats(bundle, r); >> registerTypeConverterLoader(bundle, r); >> for (BaseService service : r) { >> service.register(); >> } >> resolvers.put(bundle.getBundleId(), r); >> } >> >> return bundle; >> } >> >> private boolean extenderCapabilityWired(Bundle bundle) { >> BundleWiring wiring = bundle.adapt(BundleWiring.class); >> List<BundleWire> requiredWires = >> wiring.getRequiredWires(ExtenderNamespace.EXTENDER_NAMESPACE); >> for (BundleWire requiredWire : requiredWires) { >> if >> ("org.apache.camel".equals(requiredWire.getCapability().getAttributes().get(ExtenderNamespace.EXTENDER_NAMESPACE))) >> { >> if (this.bundleId == >> requiredWire.getProviderWiring().getBundle().getBundleId()) { >> LOG.debug("Bundle {} extender capability wired to this >> extender implementation.", bundle.getBundleId()); >> return true; >> } else { >> LOG.info("Bundle {} ignored since extender capability is >> not wired to this extender implementation.", bundle.getBundleId()); >> return false; >> } >> } >> } >> LOG.debug("Bundle {} does not require extender capability.", >> bundle.getBundleId()); >> >> return true; >> } >> ... >> >> On Fri, Mar 6, 2015 at 7:04 PM, David Jencks <[email protected]> wrote: >> 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 >>> >> >> > >
