I hadn't really either until just recently. It won't take long to pick it up. If your bean needs access to a route you just have ProducerTemplate injected. If your route needs access to a bean you just name the bean with @Named and refer to it in your route with the string "bean:myBeanName". Same for testing. If you want to test just the function of some bean you have in for validation you just refer to it in your test with @Inject and the concrete class name. Bingo. Almost like magic.
I'm like and have toiled in the blueprint XML salt mines for a few years and the change makes Camel, already a very good library, now a great library. On Fri, Sep 2, 2016 at 1:00 PM, Matt Sicker <[email protected]> wrote: > 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]> >
