Hi all, finally got this worked ! Using DS (based on spring) and the "depends-on" attribute for my bean, the bundle hangs in Waiting until the reference is satisfied !
Thanks all for help 2014-11-14 16:37 GMT+01:00 Matthieu Vincent <[email protected]>: > Thanks all for replies. > I'll have a look at DS as I do not use blueprint in this project. > > I'll you know about my results > > Mat > > 2014-11-14 10:55 GMT+01:00 CLEMENT Jean-Philippe < > [email protected]>: > >> Yes, I'm also wondering whether you really want "bundle2" to start after >> "bundle1" or you just need a service of bundle1 in bundle2. >> >> From my understanding it is rather the latter case, then it's just OSGi >> business as usual. Bundle1 takes the required time to start then publishes >> the service when usable. Bundle2 also starts and waits the service to be >> published, which can be done several ways, my preference would go to >> Blueprint. >> >> Is the service dependency sufficient, or, if not, what is the extra need? >> >> JP >> >> [@@ OPEN @@] >> >> -----Message d'origine----- >> De : Andreas Gies [mailto:[email protected]] >> Envoyé : vendredi 14 novembre 2014 10:35 >> À : [email protected] >> Objet : Re: Bundle dependency >> >> Hi there, >> >> I am not sure where you are getting at with your question…I ll try to >> answer anyway. >> >> The bundle start level is kind of a hint for the OSGi container runtime >> in which order the bundles shall be started. AFAIK this is only organising >> the invocation of the method and usually the “start up” activities of >> several bundles will run in parallel. Furthermore, for 2 bundles with the >> same start level you cannot predict the order in which the start methods >> will be called. >> >> >> Even if bundle B has a bigger startlevel than A you cannot assume that >> the initilization of A has finished by the time the start method of B is >> invoked. Especially if A registers one or more services those might not be >> available at this point in time. >> >> >> In that case you can use OSGi declarative services or the service >> injection via blueprint. Essentially those will make sure that the >> initialization of bundle B only proceed when A has registered it’s services. >> >> Personally I am using Scala/Akka for implementing my bundles and have >> wrapped the OSGI Service Tracking API inside an Actor (which is more or >> less what Blueprint or Declarative Services do as well). Using Scala and >> Akka I can simply switch the Actor state from “Services unavailable” to >> “Services available” und have functions registered that will be performed >> on state transitions. >> >> >> In a nutshell, if you have these kind of dependencies I believe you have >> to decide on one of the service tracking schemes. Also take care that >> service instances might be registered / deregistered over time and your >> bundle should react accordingly if one of it’s dependencies is not >> available. >> >> >> Hope that helps >> Andreas >> >> >> > On 13 Nov 2014, at 18:39, Matthieu Vincent <[email protected]> >> wrote: >> > >> > Hi >> > >> > I'd like to know which is the better way to have some dependency >> between 2 bundles so that a bundle will not start before its dependency is >> in an active state ? >> > >> > Thanks for answers >> > Mat >> >> >
