Just my 2 cents CAD...
I think that this effort may be leading to diminishing returns ..
there are many edge cases we may hit here, and i don't want to see
Karaf's console take minutes to become available. So here is my
alternative suggestion:
Allow Karaf console to come up as per start level as we've been doing
for a long time now, but include two new messages that will be printed
to the console screen:
1: Welcome to Karaf ${version}, bundles are still loading....
2: All bundles started, happy hacking!
The message content can be changed to suit our needs - the main thing
is that the console will be available to users right away.
Cheers,
Jamie
On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <gno...@gmail.com> wrote:
> 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
