The Camel 2.17 CDI implementation will automatically pick up the RouteBuilders. I was kicking the tires on it and was very pleased. The RouteBuilders in turn pick up their dependencies from either in bundle annotated beans and providers or from external OSGi services. Pretty slick.
Matt, do you use the XML version of DS or annotations? Brad On Sat, Aug 27, 2016 at 1:49 PM, Matt Sicker <boa...@gmail.com> wrote: > I've been using the Java DSL route builders, and you still need to use > Blueprint just to load them via <contextScan/> in the <camelContext/> > element. > > On 27 August 2016 at 13:44, Brad Johnson <brad.john...@mediadriver.com> > wrote: > >> I assume you mean blueprint XML routebuilders and not Java DSL >> routebuilders? I've used the XML approach for a long time. >> CamelBlueprintTestSupport has gotten much better but it still has >> limitations on multiple contexts and I find I'm commonly debugging the >> tests as much as making the code run right. It is also a bit slow and will >> hang on occasions. >> >> The only issue I've noticed with CDI and the OSGi annotations is that the >> CamelRunner for CDI uses Weld while the pax-cdi doesn't. That might be an >> issue. CamelSCR still feels half baked. >> >> But I don't have hard and fast opinions about it and am interested in >> different perspectives. >> >> On Sat, Aug 27, 2016 at 1:17 PM, Johan Edstrom <seij...@gmail.com> wrote: >> >>> I actually personally passionately hate not using RouteBuilders so >>> for me BP really is about inversion of control and I prefer argument >>> to properties so I can easily test the same code, not to mention >>> I never have to dig for a NPE bean wiring in large systems. >>> >>> >>> /je >>> >>> On Aug 27, 2016, at 11:44 AM, Brad Johnson <brad.john...@mediadriver.com> >>> wrote: >>> >>> Agreed that it is philosophical and can be contentious. I just started >>> using CDI via pax-cdi and Camel because Camel 2.17 has better support. Also >>> I think the pax-cdi that Guillame and I think JB Onofre created are >>> relatively new. So I've just started using and have a project using it >>> without any Blueprint XML which I've been using for the past number of >>> years. That required a switch to using the Java DSL for the routebuilder >>> but I didn't find that too painful. >>> >>> Brad >>> >>> On Sat, Aug 27, 2016 at 12:22 PM, Johan Edstrom <seij...@gmail.com> >>> wrote: >>> >>>> I’ve never seen DS used in the wild other than in places where say >>>> central infrastructure IT provides container services and frameworks. >>>> >>>> Still have to see a lot of CDI use and with PaaS offerings and Spring >>>> revamps and a lot of push BP is from what I gather the only viable >>>> alternative. >>>> >>>> Just my 0.02c. >>>> >>>> Since most developers out there just see it as a tool or necessary evil >>>> in a corporate setting, they don’t really grok services, registrations, >>>> proxies, >>>> NamespaceHandlers, SPI providers and so on anyways. >>>> >>>> I think it is a very philosophical debate. >>>> >>>> /je >>>> >>>> > On Aug 27, 2016, at 10:45 AM, Brad Johnson < >>>> brad.john...@mediadriver.com> 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. >>>> > >>>> > 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 <boa...@gmail.com> >
