http://camel.apache.org/cdi.html http://camel.apache.org/cdi-testing.html https://ops4j1.jira.com/wiki/display/PAXCDI/Cheat+Sheet
On Fri, Sep 2, 2016 at 12:34 PM, Brad Johnson <[email protected]> wrote: > Yes but doesn't the independent start up order of DS require configuration > of start up order? > > On Fri, Sep 2, 2016 at 11:30 AM, Timothy Ward <[email protected]> > wrote: > >> Hi Brad, >> >> > On 27 Aug 2016, at 17:45, Brad Johnson <[email protected]> >> wrote: >> > >> > While I understand the benefits of DS I'm wondering if it makes much >> difference for end users. I mean if I were creating a library for commons, >> XStream, Beanio or something else then it makes a lot of sense to expose it >> via DS. >> > >> > But when creating end user bundles with Camel routes, beans, >> interfaces, and OSGi services the service damping provided by blueprint >> seems like a positive benefit in that one doesn’t have to worry about start >> up order. >> >> Independence of startup ordering is a benefit of using OSGi services in >> general - it applies to DS, Blueprint, and anything else that uses the OSGi >> service registry properly. It has little to do with damping. >> >> The service damping from blueprint is actually more harmful than helpful >> in many cases. As there is never any bean destruction or re-injection there >> is no way to guarantee that the object reference you hold actually points >> at anything. When combined with blueprint’s “block for a really long time” >> behaviour on missing references this can wreak havoc in your system. >> Optional services are really horrible in this model. >> >> As things stand currently blueprint is most widely used for working with >> Camel. From what I can tell configuring Camel is horrible, and my >> understanding is that the main advantage of blueprint is that there is a >> huge amount of ready-built Camel integration available. If Camel had a >> nicer, container agnostic configuration mechanism then I would see little >> reason to choose blueprint over DS. >> >> Regards, >> >> Tim >> >> >> >> > >> > That's doubly true now that I've been working with pax-cdi and Camel. >> I'd say the development time is cut in half. The OSGiSeriviceProvider >> (sp?) annotation still uses blueprint proxies behind the scenes but I don't >> think that's a problem. What it does do is eliminate the need for all the >> XML configuration which can result in typos and other issues. >> > >> > What are the views on this? >> > >> > Brad >> >> >
