This is almost like the current solution.
The only difference is that the shell currently only starts when the
startlevel is reached or when the user presses enter.
I also thought about printing a message when karaf finished loading. The
problem is that the user might just be typing at that moment so the
message would scramble his input. This
is why the current solution waits. When the user presses enter the
progress bar is stopped and no further messages are printed. So we do
not interfere with the user input.
So I really like what we have right now and think we should not add a
further listener to the startup. Like proposed before.
The case of monitoring is completely different and I think the new
BundleService in karaf 3 can help with that case a lot like mentioned in
my other mail.
About the startup time vs run time in production Achim mentioned. This
is definately true for the long run. We should remember though that the
startup of karaf is the first thing a users sees when starting karaf for
the first time. So I think it is worth putting some effort into the
startup to make the first experience with karaf a pleasant one for the
user. For many people these first moments may decide if they are willing
to put more effort into understanding and using karaf or try the next
product.
Christian
Am 09.08.2012 13:19, schrieb Jamie G.:
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
