Ah. OK. That makes it much more palatable. I had this vision of installing 30 bundles and having to specify start up order. When you say using low level APIs I suppose you mean things like BundleActivator and it's overriden methods?
I've started working with the SCR in camel and the CDI as well. To mean it seems like a good combination since I can let the CDI wire up my bundle internals while letting SCR expose that to the world and get properties in. On Mon, Sep 5, 2016 at 6:14 AM, Timothy Ward <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> > wrote: > >> 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 >> >> > >
