Hi Christoph,
the current implementation uses the start level as an indicator to start
the shell. So the shell starts once the FRAMEWORK_BEGINNING_STARTLEVEL
is reached. As by default we start blueprint contexts synchronously this
should be a quite good indicator that all desired bundles are up or failed.
So I think the current solution already shows that karaf has fully
started. It does not show of course that the startup was successfully as
we would not want the shell
to "hang" if a bundle fails.
For Karaf 3 I have done a solution for determining if something is wrong
in the framework. I have used this in the new bundle:diag command that
shows all typical problems.
I have also enhanced the bundleService.getInfo method. It now shows that
combined status of the OSGi state and all BundleStateServices that are
available.
BundleStateService is a SPI that allows to implement a service to
determine a state and diagnostic informations for a bundle regarding a
certain technology. I have implemented this for Spring DM and Blueprint
but we could add more implementations like for DS. Users could also
implement this service to provide their own diagnostics.
This aproach is a bit different to the StartupIndicator you proposed. I
think the BundleStateService is a better option for monitoring as it
also works while the framework is running and not only ar startup. This
is important as probably once you solved the question "When is the
frameowork fully up?" the next question will be "how can we check it is
still working?".
So I think the BundleStateService which is also available in JMX is
already a nice thing to monitor. If it reports any bundle that is not
active then the admin knows soemthing is wrong.
I think we could improve the startup of the shell by displaying a
message if any non fragment bundle is in a state other than Active. Like:
"Warning some bundles did not start correctly. Type bundle:diag to get
more informations."
What do you think?
Christian
Am 08.08.2012 20:43, schrieb Christoph Gritschenberger:
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] [ Resolved] [ 20] Apache Aries Blueprint Core Compatiblity
Fragment Bundle (1.0.0), Hosts: 26
[ 47] [ Active] [ 30] Apache Karaf :: System :: Shell Commands
(3.0.0.SNAPSHOT)
[ 48] [ Active] [ 24] Apache Karaf :: Deployer :: Spring
(3.0.0.SNAPSHOT)
karaf@root()>
After a few seconds the installing of the features commences:
...
[ 47] [ Active] [ 30] Apache Karaf :: System :: Shell Commands
(3.0.0.SNAPSHOT)
[ 48] [ Active] [ 24] Apache Karaf :: Deployer :: Spring
(3.0.0.SNAPSHOT)
[ 49] [ Installed] [ 30] Apache Karaf :: ConfigAdmin :: Core
(3.0.0.SNAPSHOT)
[ 50] [ Installed] [ 30] Apache Karaf :: ConfigAdmin :: Commands
(3.0.0.SNAPSHOT)
...
So the condition "all non-fragment bundles are ACTIVE" does not
necessarily mean "startup is complete".
2. Even if all features are installed completely and all bundles are
ACTIVE, they may contain a blueprint-file and the blueprint-container
might take even longer to start up.
So I had an idea, I wanted to discuss:
How about introducing an additional interface (like "StartupIndicator"
with a method "boolean isStartupComplete()" or "int
getStartupProgress()"). The FeatureService could implement this
interface and provide the Service be registered with this additional
interface.
The Shell-bundle could then pick up all "StartupIndicator"-services and
require all of them to return true before actually showing the prompt.
Another StartupIndicator could check for BlueprintContainers to be
available.
This way, the shell would not actually have a direct dependency to the
FeatureService, but could delay the prompt until all features are
installed and active.
Another advantage is, that users would be able to implement their own
"StartupIndicator"-services to introduce even more delays.
WDYT?
kind regards,
christoph
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
