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 >> >> > >
