@gnodet I have been using the new CDI along with Camel 2.17.3 and it sounds as if I don't need the SCR at all then? So I'd be able to remove the felix scr annotations dependency? The last element in the list which I've italicized.
<dependency> <groupId>javax.enterprise</groupId> <artifactId>cdi-api</artifactId> </dependency> <dependency> <groupId>org.ops4j.pax.cdi</groupId> <artifactId>pax-cdi-api</artifactId> <version>1.0.0.RC1</version> </dependency> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-cdi</artifactId> </dependency> *<dependency>* * <groupId>org.apache.felix</groupId>* * <artifactId>org.apache.felix.scr.annotations</artifactId>* * </dependency>* On Tue, Sep 6, 2016 at 10:47 AM, Brad Johnson <[email protected]> wrote: > @gnodet > > Thanks for the info regarding the @OsgiServe/@OsgiServiceProvider. > Perhaps that's where I go the idea that one needed to specify start up > order on bundles. In some recent test projects I have been using the Felix > SCR but most of the testing has been using the CamelCDI runner as it is > very fast. That obviously creates some problems with having to double > annotate some items for Inject vs Reference and so on and the fact that CDI > isn't going to respect bundle boundaries inside the test. But that isn't a > huge problem because in the context of testing it isn't like I have 300 > bundles running. It's just a few application bundles and their > dependencies. > > It does mean I'll have to get ready to deal with some errors when moving > from the IDE environment over to the Karaf/felix environment but for > development/testing speed it definitely seems worth it. > > I'm so used to using CamelBlueprintTestSupport and blueprint.xml that all > of this still feels a bit left handed -- "If I were doing this in > blueprint, this what I'd do...." > > On Mon, Sep 5, 2016 at 6:38 AM, Guillaume Nodet <[email protected]> wrote: > >> 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 <[email protected]>: >> >>> 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 <[email protected]> wrote: >>> >>>> On 2 September 2016 at 11:30, Timothy Ward <[email protected]> >>>> 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: [email protected] >> Web: http://fusesource.com >> Blog: http://gnodet.blogspot.com/ >> >> >
