Hi Andreas,
it depends what we consider when saying "bundle started". From a OSGi
perspective, the bundle is started.
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 ;)).
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] [ 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
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
