Hi Brad, > On 27 Aug 2016, at 17:45, 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.
Independence of startup ordering is a benefit of using OSGi services in general - it applies to DS, Blueprint, and anything else that uses the OSGi service registry properly. It has little to do with damping. The service damping from blueprint is actually more harmful than helpful in many cases. As there is never any bean destruction or re-injection there is no way to guarantee that the object reference you hold actually points at anything. When combined with blueprint’s “block for a really long time” behaviour on missing references this can wreak havoc in your system. Optional services are really horrible in this model. 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. Regards, Tim > > 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
