Matt, For the past few weeks I've been working with the Camel 2.17 CDI and it's marvelous. I've been using blueprint for a few years now and I won't be going back to twiddling XML unless I have to (I'm not sure how to set up CXF server without it right now). But the CDI test runner is fast and a snap to use. The annotation automated wire up and RouteBuilder automatic running is just like you'd think ought to be.
The pax-cdi implementation actually creates blueprint proxies for annotations like @OSGiServiceProvider and will inject it where you specify the service consumer. The only caveat to the CDI test runner is that it is not OSGi based but uses Weld. So you have to be careful about what you test but I can live with that. Truly stunning when one sees a technology that works almost like magic - like you'd dream it should work. On Fri, Sep 2, 2016 at 12:04 PM, Matt Sicker <boa...@gmail.com> wrote: > On 2 September 2016 at 11:30, Timothy Ward <timothyjw...@apache.org> > wrote: > >> 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. >> > > This right here is exactly how I feel. If there was a well supported way > of simply using DS instead of Blueprint with Camel, then I'd drop Blueprint > in a single sprint and never look back. >
