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
