I've never used CDI before, but that's certainly worth looking into. Thanks.
On 2 September 2016 at 12:52, Brad Johnson <[email protected]> wrote: > 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 >>> >>> >> > -- Matt Sicker <[email protected]>
