If the Blueprint support in Camel were less Blueprint-biased and more generic to OSGi services, then I feel it would integrate much better with DS. I've been using DS for services more often lately because wiring <bean/>s in an XML file is so blasé, but I still need to use BP to load my Camel routes, and that generally requires making <reference/>s to all my DS services I would need even though they're all obtainable by the name property via service lookup (Camel won't recognise those named services as bean references unless I import them into the BlueprintContainer used by the CamelContext). Unfortunately, it might not be possible for Camel 2.x to fully support the dynamism of DS, but perhaps 3.x could have a more dynamic Registry API that allows for more proper OSGi integration. You can already start, stop, add, and remove routes and components at runtime, but as you've found, this service damping technique is still required due to certain assumptions the Camel API makes about runtime availability of the things your routes reference.
On 27 August 2016 at 13:17, 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]>
