Hi,
this is only true for Spring-DM, the blueprint spec doesn't have this.
Take also a look at the spring dm documentation in section 7.2
There is a comparison of it.
http://static.springsource.org/osgi/docs/2.0.0.M1/reference/html-single/
regards, Achim
2012/1/10 Hervé BARRAULT <herve.barra...@gmail.com>
> Hi,
> By default, the Spring context is created asynchronously but spring?
> enables you to have a synchronous one.
>
> Example by adding in your Manifest:
> Spring-Context: *;create-asynchronously:=false;timeout:=30
>
> Context is created synchronously and the bundle will be active only if
> the spring context is successfully created in less than 30 seconds.
>
>
> It link the active state of the bundle to the spring context creation.
>
> I don't know if something similar exists for Blueprint.
>
> Regards
>
>
> On 1/5/12, Freeman Fang <freeman.f...@gmail.com> wrote:
> > Hi,
> >
> > Yeah, that's correct, the scenario you described here might happen(but
> > it works in most cases), this is actually from the OSGi asyn nature.
> > And business logic depend on bundle start sequence isn't good practice
> > in OSGi world.
> >
> > The only way I know can guarantee the bundle fully start sequence is
> > hold the OSGi service reference, or use spring/blueprint event
> > listener in some cases also works, just like I mentioned in this thread.
> >
> >
> > Freeman
> >
> >
> >
> > On 2012-1-5, at 下午7:06, metatech wrote:
> >
> >>
> >> Freeman-2 wrote
> >>>
> >>> Or specify less start-level for bundle1, which means bundle1 get
> >>> started early than bundle2, you need write a feature descriptor where
> >>> you can specify start-level for each bundle.
> >>>
> >> Hi Freeman,
> >>
> >> I have a question regarding your second option.
> >>
> >> My understanding is that start-level only have an effect at the OSGi
> >> lifecycle ("Installed", "Resolved", "Active"), but not for the
> >> Spring/Blueprint lifecycle ("Started").
> >>
> >> The following scenario might happen :
> >> 1. Bundle1 is activated by the OSGi framework.
> >> 2. Bundle1 is started by Spring/Blueprint framework.
> >> 3. Bundle2 is activated by the OSGi framework.
> >> 4. Bundle2 is started by Spring/Blueprint framework.
> >>
> >> Start levels ensure that step 3 happens after step 1.
> >> Spring/Blueprint ensures that step 2 happens after step 1.
> >> Spring/Blueprint ensures that step 4 happens after step 3.
> >>
> >> Steps 2 and 3 can happen in parallel.
> >> Steps 2 and 4 can happen in parallel.
> >>
> >> In that case, bundle2 might be started before bundle1 is fully
> >> started :
> >> step 4 might be finished before step 2, especially if step 2 waits
> >> for other
> >> dependencies.
> >>
> >> Is my understanding correct ?
> >>
> >> Thanks,
> >>
> >> metatech
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://servicemix.396122.n5.nabble.com/Active-Bundle-Not-exactly-Active-tp5109090p5122383.html
> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
> >
> > ---------------------------------------------
> > Freeman Fang
> >
> > FuseSource
> > Email:ff...@fusesource.com
> > Web: fusesource.com
> > Twitter: freemanfang
> > Blog: http://freemanfang.blogspot.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
