The new annotations are org.ops4j.pax.cdi.api.Component org.ops4j.pax.cdi.api.Immediate org.ops4j.pax.cdi.api.Service ...
Those annotations are different from the SCR or DS annotations, so you clearly do not need the felix scr annotations bundle. Guillaume 2016-09-06 17:51 GMT+02:00 Brad Johnson <[email protected]>: > @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/ >>> >>> >> > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
