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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 < >>> [email protected]> 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 <[email protected]>
