As with anything that uses the OSGi Service Registry properly, DS waits for a service to be available before activating a component which uses that service. This means that there is no configuration of startup order, and that there are no points when the graph is incomplete assuming that:
a) All other bundles correctly wait for service dependencies (many do this badly if they try to use the raw OSGi API) b) All services are registered only when they are usable (again, this is hard when using the low level API) I know a large number of DS users, none of them need to use start-up ordering to make DS work. The problems that do occur happen when libraries have poorly written OSGi code which does not use a container, and instead use the low level OSGi APIs incorrectly. Regards, Tim On 2 Sep 2016, at 18:34, Brad Johnson <brad.john...@mediadriver.com<mailto:brad.john...@mediadriver.com>> wrote: Yes but doesn't the independent start up order of DS require configuration of start up order? On Fri, Sep 2, 2016 at 11:30 AM, Timothy Ward <timothyjw...@apache.org<mailto:timothyjw...@apache.org>> wrote: Hi Brad, > On 27 Aug 2016, at 17:45, Brad Johnson > <brad.john...@mediadriver.com<mailto: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. 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
