Remember extenders can start bundles asynchronously, so the ReadyService
should be registered by the extender from an activator.
I'd think aries quiesce api could be a good location for that as it could
be included in blueprint.
However, failures should be taken into account in the api, as a failed
bundle state won't change anymore.
On Thursday, August 9, 2012, Andreas Pieber wrote:
> Hey JB,
>
> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré
> <j...@nanthrax.net<javascript:;>>
> wrote:
> > Hi Andreas,
> >
> > it depends what we consider when saying "bundle started". From a OSGi
> > perspective, the bundle is started.
>
> I think there are various lvls here (and thats the reason why I
> consider the ReadyService, as proposed by Christoph, such a good
> idea). Consider that we register those ReadyServices via the activator
> they will be available once the bundle is active; once all framework
> bundles are active the feature service can state once he had installed
> all features, the deployer can state once all bundles from the deploy
> folder had been added, a custom application bundle can e.g. check if a
> specific url could be reached and so on; This could finally provide a
> "suite" which could be adapted to give a user a quite accurate "real"
> start-point (even if it requires some manual adaption). I'm really
> interested what you think about this once you've given it a little bit
> more time for consideration :-)
>
> >
> > However I'm agree about the featuresBoot (AFAIR we have a Jira about
> that).
> >
> > I will take time deeper later (time to go dinner for me here ;)).
>
> Dinner? Wow, I really should take more time keeping up-to-date; where
> the hell are you :-)
>
> Kind regards,
> Andreas
>
> >
> > Regards
> > JB
> >
> >
> > On 08/09/2012 05:08 AM, Andreas Pieber wrote:
> >>
> >> Hey guys,
> >>
> >> While the 2.3.x code looks ways more stable than the one on the master
> >> I'm not convinced that it will solve Christoph's problem. As Christoph
> >> pointed out:
> >>
> >> "There is a short delay between the point where all karaf-base-bundles
> >> are loaded and the feature-installer starts installing features
> >> specified in "featuresBoot". When starting up the first time, this
> >> almost always happens"
> >>
> >> I would say the relevant parts in Karaf 2.3.x are:
> >>
> >> a) StartupListener.java
> >> b) DelayedStarted.java
> >>
> >> So, If I'm correct (a) is printing the number of active
> >> bundles/available bundles till (b) set a constant which will occur the
> >> moment a bundle is added with a start lvl higher than
> >> "org.osgi.framework.startlevel.beginning". That's basically fine, but
> >> this will still not fix the problem with the feature service adding
> >> bundles (with even higher start lvls) AFTER the framework startup. In
> >> addition we've the "old" problem of various parts (blueprint, webapps,
> >> deployer, ...) starting up async. While most of those components know
> >> when they're finished (a) cannot know. This has the advantage that it
> >> has no problem if a bundle is e.g. caught in a startup loop, but on
> >> the other hand you wont know when all bundles are active. In addition
> >> it will show the framework ready although bundles with a startup lvl
> >> higher than "org.osgi.framework.startlevel.beginning" are still
> >> starting.
> >>
> >> Therefore I'm curious if the process shouldn't be something like
> >>
> >> a) wait till all bundles are active or one have failed
> >> b) once all bundles are active query for a StartupIndicator service
> >> and wait till all of them either return finished or failed
> >> c) once all startup indicators are finished wait again till all
> >> (possibly new bundles) are active
> >> d) now there are maybe new StartupIndicators available or everything
> >> is up and running
> >>
> >> Do I miss anything? WDYT?
> >>
> >> Kind regards,
> >> Andreas
> >>
> >> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
> >> wrote:
> >>>
> >>> Hi Christoph,
> >>>
> >>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
> >>> progress bar while Karaf is starting and the shell console arrives only
> >>> when
> >>> the startup is complete.
> >>>
> >>> I invite you to take a look on that.
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> I had another meeting with a customer today who asked me: "How can I
> >>>> tell whether it is started up completely?". ("It" being our
> karaf-based
> >>>> product)
> >>>>
> >>>> So I had a look at several alternatives how I could accomplish this
> and
> >>>> had an idea I wanted to discuss.
> >>>>
> >>>> I know that I can modify the Start-level of the Shell-bundle but I
> don't
> >>>> think that's enough.
> >>>> Recently Christian Schneider implemented something to delay the
> startup
> >>>> of the shell until all bundles are active. I think that's a good
> start,
> >>>> but does not solve the problem completely for me. I encountered
> several
> >>>> issues with the approach:
> >>>>
> >>>> 1. There is a short delay between the point where all
> karaf-base-bundles
> >>>> are loaded and the feature-installer starts installing features
> >>>> specified in "featuresBoot". When starting up the first time, this
> >>>> almost always happens
> >>>>
> >>>> ...
> >>>> [ 45] [ Active] [ 5] OPS4J Base - Lang (1.3.0)
> >>>> [ 46] [
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
