I don't really recommend using the @OsgiService / @OsgiServiceProvider of Pax-CDI. The main reason is that if the bundles are not started in the correct order, the bean validation will simply fail and your CDI app won't be created at all. I'd really recommend to look at the new annotations of Pax-CDI which haven't been released yet (in 1.0.0-SNAPSHOT). They are very similar to the DS semantics (and they actually use part of Felix SCR implementation as the core engine). The lifecycle of the CDI beans is similar to those of DS, so the dependency mechanism is really straightforward from a user point of view.
Cheers, Guillaume 2016-09-02 19:46 GMT+02:00 Brad Johnson <brad.john...@mediadriver.com>: > 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. >> > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
