karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Gritschenberger <christoph.gritschenber...@gmail.com>
Subject Telling whether startup is really complete
Date Wed, 08 Aug 2012 18:43:57 GMT

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

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
	[  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring

After a few seconds the installing of the features commences:

	[  47] [    Active] [   30] Apache Karaf :: System :: Shell Commands
	[  48] [    Active] [   24] Apache Karaf :: Deployer :: Spring
	[  49] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Core
	[  50] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Commands

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
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

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.


kind regards,

View raw message