You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Christoph Gritschenberger <ch...@gmail.com> on 2012/08/08 20:43:57 UTC

Telling whether startup is really complete

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

Re: Telling whether startup is really complete

Posted by Charles Moulliard <ch...@gmail.com>.
Hi,

>From my point of view, this is not because a bundle is started or even an
OSGI service is registered (in the OSGI registry) that we could say that
the "Services" deployed on the platform (Bundles, Camel routes, Web
Services, Web modules, ....) are operational. This is why for that reason I
always recommend to our clients that they add in their services some MBeans
methods, log trace, use WireTap EIP, ...  to capture that information and
report it into a dashboard (DataBase, ...) that operational guys can use to
be informed if everything is "operational = services well deployed and
started)

Regards,

Charles Moulliard

Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com

On Thu, Aug 9, 2012 at 5:55 AM, Andreas Pieber <an...@gmail.com> wrote:

> Hey JB,
>
> On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> 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é <jb...@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é
> >>> jbonofre@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>

Re: Telling whether startup is really complete

Posted by Christian Schneider <ch...@die-schneider.net>.
Karaf publishes an OSGi service org.apache.karaf.features.BootFinished 
when bundles are started.
Not sure if you can easily work with this on the shell.

Maybe this is also something we can enhance in the ssh based shell.
We could delay the ssh shell in the same way as the local console. That 
would solve the problem.

Christian

Am 22.12.2014 um 14:14 schrieb Prithviraj:
> Hi JB,
>
> I tried this , it displayed the message as mentioned in custom.properties
> file .
> Actually it is not solving my problem .
> My problem statement is like below
> 1) I have  wrote start_karaf.sh file  which will invoke start  script  from
> {$KARAF_HOME}/bin location .
> Which internally start the karaf in back ground mode
> 2) I have other script deploy_apps.sh which will get execute  once  previous
> start_karaf.sh  script get successfully executed.
> deploy_app.sh script is for  deploying  bundles in karaf  server.
> Since  start_karaf.sh  invoking karaf server in background , i need to know
> if  server is fully started  before  deploying apps .
> So i need  some mechanism , or  commands  by which i  can come to know
> server is  fully started  so  that i can start with bundle app deployment .
>
> Thanks in advance  for your help .
>
> Thanks
> Prithvi
>    
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037359.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.


-- 
  
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Telling whether startup is really complete

Posted by Prithviraj <me...@gmail.com>.
Hi JB,

I tried this , it displayed the message as mentioned in custom.properties
file .
Actually it is not solving my problem .
My problem statement is like below 
1) I have  wrote start_karaf.sh file  which will invoke start  script  from 
{$KARAF_HOME}/bin location .
Which internally start the karaf in back ground mode 
2) I have other script deploy_apps.sh which will get execute  once  previous
start_karaf.sh  script get successfully executed.
deploy_app.sh script is for  deploying  bundles in karaf  server.
Since  start_karaf.sh  invoking karaf server in background , i need to know
if  server is fully started  before  deploying apps . 
So i need  some mechanism , or  commands  by which i  can come to know
server is  fully started  so  that i can start with bundle app deployment .

Thanks in advance  for your help .

Thanks 
Prithvi
  




--
View this message in context: http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037359.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: Telling whether startup is really complete

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,

yes, in etc/custom.properties, you can add:

karaf.delay.console=true
karaf.startup.message=Please wait while Apache Karaf is starting...

It will delay the console display waiting features installed.

Regards
JB

On 12/22/2014 12:21 PM, Prithviraj wrote:
> I am running Karaf server on Unix .
> I have started the Karaf server in non console mode  by  executing  ./karaf
> server  command .
> Now I  want to deploy my  bundle  in  next step .
> Since server is not fully stared yet ,  my command for  deploying bundle
> getting failed .
> Is there any  way to wait till Karaf server  fully started   so  that my
> next command  will wait till server  is started and  after that bundle  get
> deployed .
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037354.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Telling whether startup is really complete

Posted by Prithviraj <me...@gmail.com>.
I am running Karaf server on Unix . 
I have started the Karaf server in non console mode  by  executing  ./karaf
server  command .
Now I  want to deploy my  bundle  in  next step .
Since server is not fully stared yet ,  my command for  deploying bundle
getting failed .
Is there any  way to wait till Karaf server  fully started   so  that my
next command  will wait till server  is started and  after that bundle  get
deployed . 




--
View this message in context: http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037354.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: Telling whether startup is really complete

Posted by Andreas Pieber <an...@gmail.com>.
nicely summed up; +1 :-)

Kind regards,
Andreas

On Thu, Aug 9, 2012 at 7:40 PM, Ioannis Canellos <io...@gmail.com> wrote:
> I've read a lot of interesting opinions and I'd like to share mine:
>
> i) The Karaf shell should start asap, unless explicitly configured. The
> enter thing is nice but should be optional imho.
> ii) Determining when Karaf is started is one thing, determining when an
> application is started is another.
> iii) A log entry that says Karaf has started sounds enough, we can
> optionally provide that info through the info command.
> iv) Different users have different needs on what started means. To cover
> all cases we could allow the user to use a configuration file that will
> contain requirements (package, service etc) and have everyone configure it
> however he wishes.
>
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Twitter: iocanel
> *

Re: Telling whether startup is really complete

Posted by Christian Schneider <ch...@die-schneider.net>.
As till now I seem to be the only one really favouring the delayed 
startup I think a vote is not necessary.
I will make the delayed start configureable and set it to false as a 
default. We can change it then if we come to another decision later.

Christian

Am 10.08.2012 11:04, schrieb Andreas Pieber:
> OK, it might be a good idea to split the discussion here... I think we
> should rather call a vote to get the default shell delay discussion to
> a point (JB?) and use this thread rather to discuss how we want to
> implement what Ioannis summed up as:
>
> "Different users have different needs on what started means. To cover
> all cases we could allow the user to use a configuration file that
> will contain requirements (package, service etc) and have everyone
> configure it however he wishes."
>
> WDYT?
>
> Kind regards,
> Andreas
>
> On Fri, Aug 10, 2012 at 10:55 AM, Achim Nierbeck
> <bc...@googlemail.com> wrote:
>> So why don't you use paxexam-karaf then, no need to use shell scripts ....
>>
>> 2012/8/10 Christian Schneider <ch...@die-schneider.net>:
>>> The scripting is mainly important for testing. You start a fresh camel,
>>> install stuff in it, do some tests and shut it down again.
>>>
>>> Perhaps the testing framework is good enough for that case. Still for some
>>> reason our test guys like to use an out of the box camel or Talend ESB and
>>> do their tests with this.
>>> Of course as they mainly use Talend ESB it should be easy to have it on in
>>> this case. So this is not a big reason to have it on by default in pure
>>> Karaf.
>>>
>>> To sum it up I would like to have the delay as a default as I think it helps
>>> beginners but from the Talend point of view having the option in the distro
>>> is good enough. So I will go with the majority.
>>>
>>> Christian
>>>
>>> Am 10.08.2012 09:55, schrieb Achim Nierbeck:
>>>
>>>> +1 on Ioannis,
>>>>
>>>> and tbh I don't see how a hit enter does improve here,
>>>> last time I used it I had to hit 4 times on enter to get a shell, so
>>>> there was in no means
>>>> any better usage then before.
>>>> Concerning using command-scripts I still don't see the issue with that,
>>>> Karaf is a Server it's not supposed to be rebooted every 5 minutes it's
>>>> build
>>>> to last for ever, or memory does us part. Just like any other container.
>>>> And from my experience with Operations I can guarantee you they are far
>>>> more
>>>> into the "where do I monitor your app?" question then "is it already
>>>> up and running?"
>>>> For operations it's far more vital to tell that the application isn't
>>>> running anymore cause they
>>>> have to guarantee certain SLAs and this is best monitored with nexus /
>>>> JMX at this point.
>>>> They don't necessarily rely on a shell, and don't care about the first
>>>> 5 minutes a process takes to
>>>> get up and running.
>>>> For developers I'd say it still sufficient to use "la" and if it isn't
>>>> available I'd say "damn you are fast" :)
>>>>
>>>> regards, Achim
>>>>
>>>> 2012/8/10 Ioannis Canellos <io...@gmail.com>:
>>>>> Christian, nobody said that waiting is bad, on the contrary it is really
>>>>> nice. Personally I find it a great idea.
>>>>> The point of argument is if it is going to be the default behavior or
>>>>> not.
>>>>>
>>>>> The problem that you describe about the new user is well known and all of
>>>>> us have been asked questions by users that fall into that problem.
>>>>>
>>>>> The question is, should this user problem impose a default startup delay
>>>>> to
>>>>> all users?
>>>>>
>>>>> --
>>>>> *Ioannis Canellos*
>>>>> *
>>>>> FuseSource <http://fusesource.com>
>>>>>
>>>>> **
>>>>> Blog: http://iocanel.blogspot.com
>>>>> **
>>>>> Twitter: iocanel
>>>>> *
>>>>
>>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>
>>
>> --
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer & Project Lead
>> OPS4J Pax for Vaadin
>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>> Lead
>> blog <http://notizblog.nierbeck.de/>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Telling whether startup is really complete

Posted by Andreas Pieber <an...@gmail.com>.
OK, it might be a good idea to split the discussion here... I think we
should rather call a vote to get the default shell delay discussion to
a point (JB?) and use this thread rather to discuss how we want to
implement what Ioannis summed up as:

"Different users have different needs on what started means. To cover
all cases we could allow the user to use a configuration file that
will contain requirements (package, service etc) and have everyone
configure it however he wishes."

WDYT?

Kind regards,
Andreas

On Fri, Aug 10, 2012 at 10:55 AM, Achim Nierbeck
<bc...@googlemail.com> wrote:
> So why don't you use paxexam-karaf then, no need to use shell scripts ....
>
> 2012/8/10 Christian Schneider <ch...@die-schneider.net>:
>> The scripting is mainly important for testing. You start a fresh camel,
>> install stuff in it, do some tests and shut it down again.
>>
>> Perhaps the testing framework is good enough for that case. Still for some
>> reason our test guys like to use an out of the box camel or Talend ESB and
>> do their tests with this.
>> Of course as they mainly use Talend ESB it should be easy to have it on in
>> this case. So this is not a big reason to have it on by default in pure
>> Karaf.
>>
>> To sum it up I would like to have the delay as a default as I think it helps
>> beginners but from the Talend point of view having the option in the distro
>> is good enough. So I will go with the majority.
>>
>> Christian
>>
>> Am 10.08.2012 09:55, schrieb Achim Nierbeck:
>>
>>> +1 on Ioannis,
>>>
>>> and tbh I don't see how a hit enter does improve here,
>>> last time I used it I had to hit 4 times on enter to get a shell, so
>>> there was in no means
>>> any better usage then before.
>>> Concerning using command-scripts I still don't see the issue with that,
>>> Karaf is a Server it's not supposed to be rebooted every 5 minutes it's
>>> build
>>> to last for ever, or memory does us part. Just like any other container.
>>> And from my experience with Operations I can guarantee you they are far
>>> more
>>> into the "where do I monitor your app?" question then "is it already
>>> up and running?"
>>> For operations it's far more vital to tell that the application isn't
>>> running anymore cause they
>>> have to guarantee certain SLAs and this is best monitored with nexus /
>>> JMX at this point.
>>> They don't necessarily rely on a shell, and don't care about the first
>>> 5 minutes a process takes to
>>> get up and running.
>>> For developers I'd say it still sufficient to use "la" and if it isn't
>>> available I'd say "damn you are fast" :)
>>>
>>> regards, Achim
>>>
>>> 2012/8/10 Ioannis Canellos <io...@gmail.com>:
>>>>
>>>> Christian, nobody said that waiting is bad, on the contrary it is really
>>>> nice. Personally I find it a great idea.
>>>> The point of argument is if it is going to be the default behavior or
>>>> not.
>>>>
>>>> The problem that you describe about the new user is well known and all of
>>>> us have been asked questions by users that fall into that problem.
>>>>
>>>> The question is, should this user problem impose a default startup delay
>>>> to
>>>> all users?
>>>>
>>>> --
>>>> *Ioannis Canellos*
>>>> *
>>>> FuseSource <http://fusesource.com>
>>>>
>>>> **
>>>> Blog: http://iocanel.blogspot.com
>>>> **
>>>> Twitter: iocanel
>>>> *
>>>
>>>
>>>
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> OPS4J Pax for Vaadin
> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
> Lead
> blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by Achim Nierbeck <bc...@googlemail.com>.
So why don't you use paxexam-karaf then, no need to use shell scripts ....

2012/8/10 Christian Schneider <ch...@die-schneider.net>:
> The scripting is mainly important for testing. You start a fresh camel,
> install stuff in it, do some tests and shut it down again.
>
> Perhaps the testing framework is good enough for that case. Still for some
> reason our test guys like to use an out of the box camel or Talend ESB and
> do their tests with this.
> Of course as they mainly use Talend ESB it should be easy to have it on in
> this case. So this is not a big reason to have it on by default in pure
> Karaf.
>
> To sum it up I would like to have the delay as a default as I think it helps
> beginners but from the Talend point of view having the option in the distro
> is good enough. So I will go with the majority.
>
> Christian
>
> Am 10.08.2012 09:55, schrieb Achim Nierbeck:
>
>> +1 on Ioannis,
>>
>> and tbh I don't see how a hit enter does improve here,
>> last time I used it I had to hit 4 times on enter to get a shell, so
>> there was in no means
>> any better usage then before.
>> Concerning using command-scripts I still don't see the issue with that,
>> Karaf is a Server it's not supposed to be rebooted every 5 minutes it's
>> build
>> to last for ever, or memory does us part. Just like any other container.
>> And from my experience with Operations I can guarantee you they are far
>> more
>> into the "where do I monitor your app?" question then "is it already
>> up and running?"
>> For operations it's far more vital to tell that the application isn't
>> running anymore cause they
>> have to guarantee certain SLAs and this is best monitored with nexus /
>> JMX at this point.
>> They don't necessarily rely on a shell, and don't care about the first
>> 5 minutes a process takes to
>> get up and running.
>> For developers I'd say it still sufficient to use "la" and if it isn't
>> available I'd say "damn you are fast" :)
>>
>> regards, Achim
>>
>> 2012/8/10 Ioannis Canellos <io...@gmail.com>:
>>>
>>> Christian, nobody said that waiting is bad, on the contrary it is really
>>> nice. Personally I find it a great idea.
>>> The point of argument is if it is going to be the default behavior or
>>> not.
>>>
>>> The problem that you describe about the new user is well known and all of
>>> us have been asked questions by users that fall into that problem.
>>>
>>> The question is, should this user problem impose a default startup delay
>>> to
>>> all users?
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>> FuseSource <http://fusesource.com>
>>>
>>> **
>>> Blog: http://iocanel.blogspot.com
>>> **
>>> Twitter: iocanel
>>> *
>>
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>



-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by Christian Schneider <ch...@die-schneider.net>.
The scripting is mainly important for testing. You start a fresh camel, 
install stuff in it, do some tests and shut it down again.

Perhaps the testing framework is good enough for that case. Still for 
some reason our test guys like to use an out of the box camel or Talend 
ESB and do their tests with this.
Of course as they mainly use Talend ESB it should be easy to have it on 
in this case. So this is not a big reason to have it on by default in 
pure Karaf.

To sum it up I would like to have the delay as a default as I think it 
helps beginners but from the Talend point of view having the option in 
the distro is good enough. So I will go with the majority.

Christian

Am 10.08.2012 09:55, schrieb Achim Nierbeck:
> +1 on Ioannis,
>
> and tbh I don't see how a hit enter does improve here,
> last time I used it I had to hit 4 times on enter to get a shell, so
> there was in no means
> any better usage then before.
> Concerning using command-scripts I still don't see the issue with that,
> Karaf is a Server it's not supposed to be rebooted every 5 minutes it's build
> to last for ever, or memory does us part. Just like any other container.
> And from my experience with Operations I can guarantee you they are far more
> into the "where do I monitor your app?" question then "is it already
> up and running?"
> For operations it's far more vital to tell that the application isn't
> running anymore cause they
> have to guarantee certain SLAs and this is best monitored with nexus /
> JMX at this point.
> They don't necessarily rely on a shell, and don't care about the first
> 5 minutes a process takes to
> get up and running.
> For developers I'd say it still sufficient to use "la" and if it isn't
> available I'd say "damn you are fast" :)
>
> regards, Achim
>
> 2012/8/10 Ioannis Canellos <io...@gmail.com>:
>> Christian, nobody said that waiting is bad, on the contrary it is really
>> nice. Personally I find it a great idea.
>> The point of argument is if it is going to be the default behavior or not.
>>
>> The problem that you describe about the new user is well known and all of
>> us have been asked questions by users that fall into that problem.
>>
>> The question is, should this user problem impose a default startup delay to
>> all users?
>>
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource <http://fusesource.com>
>>
>> **
>> Blog: http://iocanel.blogspot.com
>> **
>> Twitter: iocanel
>> *
>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Telling whether startup is really complete

Posted by Achim Nierbeck <bc...@googlemail.com>.
+1

2012/8/9 Johan Edstrom <se...@gmail.com>:
> I actually completely disagree.
> I don't think delaying a start is good, I think logging / screaming why it isn't starting might be good.
>
> On Aug 9, 2012, at 12:48 PM, Christian Schneider wrote:
>
>> I mostly agree besides for the default. I think we all agree that the delayed start of the console is the better option for beginners while
>> a lot of karaf developers like the console that starts directly.
>>
>> For this reason I think we should have the delayed start as default for two reasons:
>> 1. We are only a handfull of developers while there are thousands of users and most are beginners or at least do not have a deep understanding of karaf.
>> 2. The delayed start is a nice out of the box experience for people who start karaf for the first time. Especially the beginners will not find the option to turn this on easily
>>
>> Christian
>>
>> Am 09.08.2012 19:40, schrieb Ioannis Canellos:
>>> I've read a lot of interesting opinions and I'd like to share mine:
>>>
>>> i) The Karaf shell should start asap, unless explicitly configured. The
>>> enter thing is nice but should be optional imho.
>>> ii) Determining when Karaf is started is one thing, determining when an
>>> application is started is another.
>>> iii) A log entry that says Karaf has started sounds enough, we can
>>> optionally provide that info through the info command.
>>> iv) Different users have different needs on what started means. To cover
>>> all cases we could allow the user to use a configuration file that will
>>> contain requirements (package, service etc) and have everyone configure it
>>> however he wishes.
>>>
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>



-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by Achim Nierbeck <bc...@googlemail.com>.
+1 on Ioannis,

and tbh I don't see how a hit enter does improve here,
last time I used it I had to hit 4 times on enter to get a shell, so
there was in no means
any better usage then before.
Concerning using command-scripts I still don't see the issue with that,
Karaf is a Server it's not supposed to be rebooted every 5 minutes it's build
to last for ever, or memory does us part. Just like any other container.
And from my experience with Operations I can guarantee you they are far more
into the "where do I monitor your app?" question then "is it already
up and running?"
For operations it's far more vital to tell that the application isn't
running anymore cause they
have to guarantee certain SLAs and this is best monitored with nexus /
JMX at this point.
They don't necessarily rely on a shell, and don't care about the first
5 minutes a process takes to
get up and running.
For developers I'd say it still sufficient to use "la" and if it isn't
available I'd say "damn you are fast" :)

regards, Achim

2012/8/10 Ioannis Canellos <io...@gmail.com>:
> Christian, nobody said that waiting is bad, on the contrary it is really
> nice. Personally I find it a great idea.
> The point of argument is if it is going to be the default behavior or not.
>
> The problem that you describe about the new user is well known and all of
> us have been asked questions by users that fall into that problem.
>
> The question is, should this user problem impose a default startup delay to
> all users?
>
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Twitter: iocanel
> *



-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by Ioannis Canellos <io...@gmail.com>.
Christian, nobody said that waiting is bad, on the contrary it is really
nice. Personally I find it a great idea.
The point of argument is if it is going to be the default behavior or not.

The problem that you describe about the new user is well known and all of
us have been asked questions by users that fall into that problem.

The question is, should this user problem impose a default startup delay to
all users?

-- 
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>

**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*

Re: Telling whether startup is really complete

Posted by Christian Schneider <ch...@die-schneider.net>.
So what are the reasons why you dislike it? Delaying the start of the 
shell till the deisred runlevel is reached mainly has the goal that all 
commands are availble.

Currently we have this in 2.2.x:
A beginner types a command he knows should work on the shell as soon as 
it opens. It complains that the command is not found. We developers all 
know why this happens and know the commands will be there shortly.

You start karaf and then want to execute a script on it using e.g. 
bin/client or ssh. The script fails as not all commands are available. 
You run the script again and it works. So you will introduce a delay of 
some seconds before you start the script. This works sometimes and 
sometimes not.

How do you solve these problems without the delay and why do you think 
it is bad?

Of course logging a failure in the startup and logging when it is 
complete (at least runlevel wise) is a good idea but it does not help 
with the above cases.

Christian

Am 09.08.2012 21:08, schrieb Johan Edstrom:
> I actually completely disagree.
> I don't think delaying a start is good, I think logging / screaming why it isn't starting might be good.
>
> On Aug 9, 2012, at 12:48 PM, Christian Schneider wrote:
>
>> I mostly agree besides for the default. I think we all agree that the delayed start of the console is the better option for beginners while
>> a lot of karaf developers like the console that starts directly.
>>
>> For this reason I think we should have the delayed start as default for two reasons:
>> 1. We are only a handfull of developers while there are thousands of users and most are beginners or at least do not have a deep understanding of karaf.
>> 2. The delayed start is a nice out of the box experience for people who start karaf for the first time. Especially the beginners will not find the option to turn this on easily
>>
>> Christian
>>
>> Am 09.08.2012 19:40, schrieb Ioannis Canellos:
>>> I've read a lot of interesting opinions and I'd like to share mine:
>>>
>>> i) The Karaf shell should start asap, unless explicitly configured. The
>>> enter thing is nice but should be optional imho.
>>> ii) Determining when Karaf is started is one thing, determining when an
>>> application is started is another.
>>> iii) A log entry that says Karaf has started sounds enough, we can
>>> optionally provide that info through the info command.
>>> iv) Different users have different needs on what started means. To cover
>>> all cases we could allow the user to use a configuration file that will
>>> contain requirements (package, service etc) and have everyone configure it
>>> however he wishes.
>>>
>>
>> -- 
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Telling whether startup is really complete

Posted by Johan Edstrom <se...@gmail.com>.
I actually completely disagree.
I don't think delaying a start is good, I think logging / screaming why it isn't starting might be good.

On Aug 9, 2012, at 12:48 PM, Christian Schneider wrote:

> I mostly agree besides for the default. I think we all agree that the delayed start of the console is the better option for beginners while
> a lot of karaf developers like the console that starts directly.
> 
> For this reason I think we should have the delayed start as default for two reasons:
> 1. We are only a handfull of developers while there are thousands of users and most are beginners or at least do not have a deep understanding of karaf.
> 2. The delayed start is a nice out of the box experience for people who start karaf for the first time. Especially the beginners will not find the option to turn this on easily
> 
> Christian
> 
> Am 09.08.2012 19:40, schrieb Ioannis Canellos:
>> I've read a lot of interesting opinions and I'd like to share mine:
>> 
>> i) The Karaf shell should start asap, unless explicitly configured. The
>> enter thing is nice but should be optional imho.
>> ii) Determining when Karaf is started is one thing, determining when an
>> application is started is another.
>> iii) A log entry that says Karaf has started sounds enough, we can
>> optionally provide that info through the info command.
>> iv) Different users have different needs on what started means. To cover
>> all cases we could allow the user to use a configuration file that will
>> contain requirements (package, service etc) and have everyone configure it
>> however he wishes.
>> 
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>

Re: Telling whether startup is really complete

Posted by Christian Schneider <ch...@die-schneider.net>.
Good point with the progress bar. I also think it looks odd when it goes 
back. I am thinking about making it only change when it actually goes 
up. So the idea is to store the current percentage and only display a 
new bar if the new percentage is higher. Technically this is not a 
correct as the current solution but I think it looks more consistent. I 
would also like to make sure it always ends with 100% in case of a 
succesfull start so the user has the confidence that all went nicely.

Christian

Am 10.08.2012 10:01, schrieb Christoph Gritschenberger:
> Hi,
>
> Seems I started a somehow more fundamental discussion here about whether
> karaf-startup should be delayed at all.
>
> As far as I can tell now there seems to be some common ground now.
> Ioannis summed it up pretty good: Providing some method of configuring
> startup-delays OK. That's also what I had in mind.
>
> I actually don't have a strong opinion about what should be karaf
> default. There are valid points on both sides. I personally have no
> problem with the "Press Enter"-approach but that's just me.
> The progress bar looks a bit odd, because it may revert to less progress
> when new bundles are installed by e.g. the features-installer.
>
> kind regards,
> christoph
>
> On 09/08/12 21:09, Achim Nierbeck wrote:
>> Christian,
>>
>> I'm sorry but I don't see any agreement on delay beeing the better
>> option, or beeing the default.
>> If you think it's ok to have the delay for your customers I'm fine if
>> you apply it to your custom distribution.
>> I'm also fine with opening a way to tell the shell how long it should
>> wait. I'm also fine to keep the "locked" shell
>> in Karaf for people to use for their own distribution.
>> So I'm +1 for the sum-up of Ioannis.
>>
>> @Johan
>> how about a "Karaf started in MM:SS" in log :-D
>>
>> regards, Achim
>>
>> 2012/8/9 Christian Schneider <ch...@die-schneider.net>:
>>> I mostly agree besides for the default. I think we all agree that the
>>> delayed start of the console is the better option for beginners while
>>> a lot of karaf developers like the console that starts directly.
>>>
>>> For this reason I think we should have the delayed start as default for two
>>> reasons:
>>> 1. We are only a handfull of developers while there are thousands of users
>>> and most are beginners or at least do not have a deep understanding of
>>> karaf.
>>> 2. The delayed start is a nice out of the box experience for people who
>>> start karaf for the first time. Especially the beginners will not find the
>>> option to turn this on easily
>>>
>>> Christian
>>>
>>> Am 09.08.2012 19:40, schrieb Ioannis Canellos:
>>>
>>>> I've read a lot of interesting opinions and I'd like to share mine:
>>>>
>>>> i) The Karaf shell should start asap, unless explicitly configured. The
>>>> enter thing is nice but should be optional imho.
>>>> ii) Determining when Karaf is started is one thing, determining when an
>>>> application is started is another.
>>>> iii) A log entry that says Karaf has started sounds enough, we can
>>>> optionally provide that info through the info command.
>>>> iv) Different users have different needs on what started means. To cover
>>>> all cases we could allow the user to use a configuration file that will
>>>> contain requirements (package, service etc) and have everyone configure it
>>>> however he wishes.
>>>>
>>>
>>> --
>>>   Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>
>>
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Telling whether startup is really complete

Posted by Christoph Gritschenberger <ch...@gmail.com>.
Hi,

Seems I started a somehow more fundamental discussion here about whether
karaf-startup should be delayed at all.

As far as I can tell now there seems to be some common ground now.
Ioannis summed it up pretty good: Providing some method of configuring
startup-delays OK. That's also what I had in mind.

I actually don't have a strong opinion about what should be karaf
default. There are valid points on both sides. I personally have no
problem with the "Press Enter"-approach but that's just me.
The progress bar looks a bit odd, because it may revert to less progress
when new bundles are installed by e.g. the features-installer.

kind regards,
christoph

On 09/08/12 21:09, Achim Nierbeck wrote:
> Christian,
> 
> I'm sorry but I don't see any agreement on delay beeing the better
> option, or beeing the default.
> If you think it's ok to have the delay for your customers I'm fine if
> you apply it to your custom distribution.
> I'm also fine with opening a way to tell the shell how long it should
> wait. I'm also fine to keep the "locked" shell
> in Karaf for people to use for their own distribution.
> So I'm +1 for the sum-up of Ioannis.
> 
> @Johan
> how about a "Karaf started in MM:SS" in log :-D
> 
> regards, Achim
> 
> 2012/8/9 Christian Schneider <ch...@die-schneider.net>:
>> I mostly agree besides for the default. I think we all agree that the
>> delayed start of the console is the better option for beginners while
>> a lot of karaf developers like the console that starts directly.
>>
>> For this reason I think we should have the delayed start as default for two
>> reasons:
>> 1. We are only a handfull of developers while there are thousands of users
>> and most are beginners or at least do not have a deep understanding of
>> karaf.
>> 2. The delayed start is a nice out of the box experience for people who
>> start karaf for the first time. Especially the beginners will not find the
>> option to turn this on easily
>>
>> Christian
>>
>> Am 09.08.2012 19:40, schrieb Ioannis Canellos:
>>
>>> I've read a lot of interesting opinions and I'd like to share mine:
>>>
>>> i) The Karaf shell should start asap, unless explicitly configured. The
>>> enter thing is nice but should be optional imho.
>>> ii) Determining when Karaf is started is one thing, determining when an
>>> application is started is another.
>>> iii) A log entry that says Karaf has started sounds enough, we can
>>> optionally provide that info through the info command.
>>> iv) Different users have different needs on what started means. To cover
>>> all cases we could allow the user to use a configuration file that will
>>> contain requirements (package, service etc) and have everyone configure it
>>> however he wishes.
>>>
>>
>>
>> --
>>  Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
> 
> 
>

Re: Telling whether startup is really complete

Posted by Achim Nierbeck <bc...@googlemail.com>.
Christian,

I'm sorry but I don't see any agreement on delay beeing the better
option, or beeing the default.
If you think it's ok to have the delay for your customers I'm fine if
you apply it to your custom distribution.
I'm also fine with opening a way to tell the shell how long it should
wait. I'm also fine to keep the "locked" shell
in Karaf for people to use for their own distribution.
So I'm +1 for the sum-up of Ioannis.

@Johan
how about a "Karaf started in MM:SS" in log :-D

regards, Achim

2012/8/9 Christian Schneider <ch...@die-schneider.net>:
> I mostly agree besides for the default. I think we all agree that the
> delayed start of the console is the better option for beginners while
> a lot of karaf developers like the console that starts directly.
>
> For this reason I think we should have the delayed start as default for two
> reasons:
> 1. We are only a handfull of developers while there are thousands of users
> and most are beginners or at least do not have a deep understanding of
> karaf.
> 2. The delayed start is a nice out of the box experience for people who
> start karaf for the first time. Especially the beginners will not find the
> option to turn this on easily
>
> Christian
>
> Am 09.08.2012 19:40, schrieb Ioannis Canellos:
>
>> I've read a lot of interesting opinions and I'd like to share mine:
>>
>> i) The Karaf shell should start asap, unless explicitly configured. The
>> enter thing is nice but should be optional imho.
>> ii) Determining when Karaf is started is one thing, determining when an
>> application is started is another.
>> iii) A log entry that says Karaf has started sounds enough, we can
>> optionally provide that info through the info command.
>> iv) Different users have different needs on what started means. To cover
>> all cases we could allow the user to use a configuration file that will
>> contain requirements (package, service etc) and have everyone configure it
>> however he wishes.
>>
>
>
> --
>  Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>



-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by Christian Schneider <ch...@die-schneider.net>.
I mostly agree besides for the default. I think we all agree that the 
delayed start of the console is the better option for beginners while
a lot of karaf developers like the console that starts directly.

For this reason I think we should have the delayed start as default for 
two reasons:
1. We are only a handfull of developers while there are thousands of 
users and most are beginners or at least do not have a deep 
understanding of karaf.
2. The delayed start is a nice out of the box experience for people who 
start karaf for the first time. Especially the beginners will not find 
the option to turn this on easily

Christian

Am 09.08.2012 19:40, schrieb Ioannis Canellos:
> I've read a lot of interesting opinions and I'd like to share mine:
>
> i) The Karaf shell should start asap, unless explicitly configured. The
> enter thing is nice but should be optional imho.
> ii) Determining when Karaf is started is one thing, determining when an
> application is started is another.
> iii) A log entry that says Karaf has started sounds enough, we can
> optionally provide that info through the info command.
> iv) Different users have different needs on what started means. To cover
> all cases we could allow the user to use a configuration file that will
> contain requirements (package, service etc) and have everyone configure it
> however he wishes.
>


-- 
  
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: Telling whether startup is really complete

Posted by Ioannis Canellos <io...@gmail.com>.
I've read a lot of interesting opinions and I'd like to share mine:

i) The Karaf shell should start asap, unless explicitly configured. The
enter thing is nice but should be optional imho.
ii) Determining when Karaf is started is one thing, determining when an
application is started is another.
iii) A log entry that says Karaf has started sounds enough, we can
optionally provide that info through the info command.
iv) Different users have different needs on what started means. To cover
all cases we could allow the user to use a configuration file that will
contain requirements (package, service etc) and have everyone configure it
however he wishes.

-- 
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>

**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*

Re: Telling whether startup is really complete

Posted by Andreas Pieber <an...@gmail.com>.
what do you mean?

Kind regards,
Andreas

On Thu, Aug 9, 2012 at 6:45 PM, Johan Edstrom <se...@gmail.com> wrote:
> What about logging?
> Sorry :)
> On Aug 9, 2012, at 10:43 AM, Andreas Pieber wrote:
>
>> After reading the entire thread again I think we've got our wires
>> crossed. The entire point is NOT (!) to make Karaf waiting for
>> anything to start up per default; I second Christoph at this point: I
>> think it's best if the default Karaf download works exactly as it does
>> in the 2.2.x branch: getting the console up as fast as possible.
>> Independently, most of us had been confronted by one or the other
>> customer/partner, ... "When can I access my services"; typically I
>> just want to stand up in such situations, punch their faces and tell
>> them "once they work, they're ready"... Well, since those are my/our
>> customers this might not be the best solution. And this is where
>> Christians approach comes in handy: hide the console by default till
>> everything "is ready". As mentioned now by various ppl already: when
>> is the system ready; well, as JB said, Karaf as a small and neat
>> container does not have to find out; this is (IMHO) nothing we can
>> solve usefully at a central place for all and everything, BUT we can
>> solve it for our customers and their/our custom distributions by e.g.
>> placing a bundle doing all the logic and simply saying when Karaf is
>> ready.
>>
>> So, back to the requirements; what do we need
>>
>> a) per default nothing than we have now
>> b) if we deliver a distribution it would be nice if we can switch a
>> flag and the karaf console wont appear till my bundle says that its
>> ready
>>
>> Basically Christians/Guillaume algorithms are almost enough for this:
>> once all bundles are active they had the chance to register a
>> "ReadService" via the activator. Waiting that those also get active
>> should be almost enough: why? Because my typical customer/project
>> partner has no real chance to find any errors in those phases on
>> himself anyhow --> he'll send me the log if the Shell isn't up in
>> 10min --> we don't need to care if those services hang forever.
>> NOTHING of this is Karaf business; it would just be nice having some
>> extension point to extend the console wait time till I as a
>> distribution adapter say that it's ready.
>>
>> And just to make it clear another time: I DON'T want to handle camel
>> routes, blueprint, cxf or whatever in karaf! We (as Karaf) don't care
>> about:
>>
>> "- when the application server itself is up and running ?
>> - when the resources in the application server are up (datasource, JMS
>> server, etc) ?
>> - when the applications are started ?"
>>
>> For Karaf it's not relevant which of those things hide behind the
>> "ReadyServices"; we don't implement them! We just wait till all
>> registered "ReadyServices" say go and start the shell then; nothing
>> more and nothing less, just give distribution adapters a tool to
>> satisfy their customers :-)
>>
>> I hope I was able to clear up things a little bit,
>> Kind regards,
>> Andreas
>>
>> On Thu, Aug 9, 2012 at 5:44 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
>>> @Charles, JB
>>>
>>> I fully agree with you, where is the line to be drawn here?
>>>
>>> Well anyone who is developing with Karaf should know it's a totally
>>> different way of working instead of using a bloated JEE-Container.
>>> This discussion somehow reminds me of a thread I once read on the
>>> felix-ml "I don't want to develop OSGi I just want to use it".
>>>
>>> As far as I'm concerned you shouldn't "Develop" OSGi but you have to
>>> get used to some constraints and projecting those to Karaf it's like
>>> this, if the container is running you have a shell but it doesn't say
>>> you application is running.
>>> The bad thing about it is, all those people are used to live without,
>>> neither JBoss nor Tomcat provide a shell.
>>> Oh wait they do, it's just the std. plain HTML stuff and guess what
>>> sometimes the std. wars are already up and running but your own isn't.
>>> Now what are we expecting of Tomcat to do? Is tomcat supposed to serve
>>> no content unless all wars are up an running?
>>> People just got used to slow running Web-applications that they don't
>>> feel comfortable when beeing able to work faster it seems ...
>>>
>>> again just my 2 cents
>>>
>>> regards, Achim
>>>
>>> 2012/8/9 Charles Moulliard <ch...@gmail.com>:
>>>> Well said JB. This is exactly what I have explained this morning.
>>>>
>>>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm not fully agree.
>>>>>
>>>>> Karaf is a container, with the purpose to be fast, lightweight.
>>>>> So what does it mean "Karaf started" ?
>>>>>
>>>>> For instance, I gonna compare with JEE application server. When do you
>>>>> consider that an application server is started:
>>>>> - when the application server itself is up and running ?
>>>>> - when the resources in the application server are up (datasource, JMS
>>>>> server, etc) ?
>>>>> - when the applications are started ?
>>>>>
>>>>> All is question of perspective.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>>>>>
>>>>>> I understand that when using karaf as a developer one would want the
>>>>>> shell as fast as possible and don't wait for a minute or something.
>>>>>> That's why Christian implemented the "Press Enter to start it
>>>>>> anyway"-thing I think.
>>>>>> Maybe it's a better option to make it optional after all and disable it
>>>>>> in the karaf-distributions, but allowing users to modify some
>>>>>> config-file to get the delayed-console-startup.
>>>>>> This way developers are not annoyed by long startup-times, but
>>>>>> karaf-based products could provide the user with proper feedback.
>>>>>>
>>>>>> And about the uptime vs startup time: I agree with Christian here. But
>>>>>> we have a customer who develops his own external systems that interact
>>>>>> with our karaf-based application. Their developers complained, they
>>>>>> can't tell when karaf is started, and they need to start and stop it
>>>>>> more often during development, but don't really want to get into karaf
>>>>>> to deeply because it's just an external system.
>>>>>>
>>>>>> I could also try to implement something like that myself. The solution
>>>>>> with the "StartupIndicator"-services makes it easier to maintain because
>>>>>> I can describe the conditions to be met in the corresponding bundle
>>>>>> (which I reuse in several assemblies).
>>>>>> I could create an additional bundle querying those services and delay
>>>>>> the console with the right use of start-levels.
>>>>>>
>>>>>> But at some points a tighter integration into karaf would be nice (like
>>>>>> the FeatureService).
>>>>>>
>>>>>> kind regards,
>>>>>> christoph
>>>>>>
>>>>>>
>>>>>> On 09/08/12 13:59, Christian Schneider wrote:
>>>>>>
>>>>>>> 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 <gn...@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é
>>>>>>>>>> <jb@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é
>>>>>>>>>>>> <jb...@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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Charles Moulliard
>>>> Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>>> Twitter : @cmoulliard
>>>> Blog : http://cmoulliard.blogspot.com
>>>
>>>
>>>
>>> --
>>>
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>> Committer & Project Lead
>>> OPS4J Pax for Vaadin
>>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>>> Lead
>>> blog <http://notizblog.nierbeck.de/>
>

Re: Telling whether startup is really complete

Posted by Johan Edstrom <se...@gmail.com>.
What about logging?
Sorry :)
On Aug 9, 2012, at 10:43 AM, Andreas Pieber wrote:

> After reading the entire thread again I think we've got our wires
> crossed. The entire point is NOT (!) to make Karaf waiting for
> anything to start up per default; I second Christoph at this point: I
> think it's best if the default Karaf download works exactly as it does
> in the 2.2.x branch: getting the console up as fast as possible.
> Independently, most of us had been confronted by one or the other
> customer/partner, ... "When can I access my services"; typically I
> just want to stand up in such situations, punch their faces and tell
> them "once they work, they're ready"... Well, since those are my/our
> customers this might not be the best solution. And this is where
> Christians approach comes in handy: hide the console by default till
> everything "is ready". As mentioned now by various ppl already: when
> is the system ready; well, as JB said, Karaf as a small and neat
> container does not have to find out; this is (IMHO) nothing we can
> solve usefully at a central place for all and everything, BUT we can
> solve it for our customers and their/our custom distributions by e.g.
> placing a bundle doing all the logic and simply saying when Karaf is
> ready.
> 
> So, back to the requirements; what do we need
> 
> a) per default nothing than we have now
> b) if we deliver a distribution it would be nice if we can switch a
> flag and the karaf console wont appear till my bundle says that its
> ready
> 
> Basically Christians/Guillaume algorithms are almost enough for this:
> once all bundles are active they had the chance to register a
> "ReadService" via the activator. Waiting that those also get active
> should be almost enough: why? Because my typical customer/project
> partner has no real chance to find any errors in those phases on
> himself anyhow --> he'll send me the log if the Shell isn't up in
> 10min --> we don't need to care if those services hang forever.
> NOTHING of this is Karaf business; it would just be nice having some
> extension point to extend the console wait time till I as a
> distribution adapter say that it's ready.
> 
> And just to make it clear another time: I DON'T want to handle camel
> routes, blueprint, cxf or whatever in karaf! We (as Karaf) don't care
> about:
> 
> "- when the application server itself is up and running ?
> - when the resources in the application server are up (datasource, JMS
> server, etc) ?
> - when the applications are started ?"
> 
> For Karaf it's not relevant which of those things hide behind the
> "ReadyServices"; we don't implement them! We just wait till all
> registered "ReadyServices" say go and start the shell then; nothing
> more and nothing less, just give distribution adapters a tool to
> satisfy their customers :-)
> 
> I hope I was able to clear up things a little bit,
> Kind regards,
> Andreas
> 
> On Thu, Aug 9, 2012 at 5:44 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
>> @Charles, JB
>> 
>> I fully agree with you, where is the line to be drawn here?
>> 
>> Well anyone who is developing with Karaf should know it's a totally
>> different way of working instead of using a bloated JEE-Container.
>> This discussion somehow reminds me of a thread I once read on the
>> felix-ml "I don't want to develop OSGi I just want to use it".
>> 
>> As far as I'm concerned you shouldn't "Develop" OSGi but you have to
>> get used to some constraints and projecting those to Karaf it's like
>> this, if the container is running you have a shell but it doesn't say
>> you application is running.
>> The bad thing about it is, all those people are used to live without,
>> neither JBoss nor Tomcat provide a shell.
>> Oh wait they do, it's just the std. plain HTML stuff and guess what
>> sometimes the std. wars are already up and running but your own isn't.
>> Now what are we expecting of Tomcat to do? Is tomcat supposed to serve
>> no content unless all wars are up an running?
>> People just got used to slow running Web-applications that they don't
>> feel comfortable when beeing able to work faster it seems ...
>> 
>> again just my 2 cents
>> 
>> regards, Achim
>> 
>> 2012/8/9 Charles Moulliard <ch...@gmail.com>:
>>> Well said JB. This is exactly what I have explained this morning.
>>> 
>>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I'm not fully agree.
>>>> 
>>>> Karaf is a container, with the purpose to be fast, lightweight.
>>>> So what does it mean "Karaf started" ?
>>>> 
>>>> For instance, I gonna compare with JEE application server. When do you
>>>> consider that an application server is started:
>>>> - when the application server itself is up and running ?
>>>> - when the resources in the application server are up (datasource, JMS
>>>> server, etc) ?
>>>> - when the applications are started ?
>>>> 
>>>> All is question of perspective.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>> 
>>>> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>>>> 
>>>>> I understand that when using karaf as a developer one would want the
>>>>> shell as fast as possible and don't wait for a minute or something.
>>>>> That's why Christian implemented the "Press Enter to start it
>>>>> anyway"-thing I think.
>>>>> Maybe it's a better option to make it optional after all and disable it
>>>>> in the karaf-distributions, but allowing users to modify some
>>>>> config-file to get the delayed-console-startup.
>>>>> This way developers are not annoyed by long startup-times, but
>>>>> karaf-based products could provide the user with proper feedback.
>>>>> 
>>>>> And about the uptime vs startup time: I agree with Christian here. But
>>>>> we have a customer who develops his own external systems that interact
>>>>> with our karaf-based application. Their developers complained, they
>>>>> can't tell when karaf is started, and they need to start and stop it
>>>>> more often during development, but don't really want to get into karaf
>>>>> to deeply because it's just an external system.
>>>>> 
>>>>> I could also try to implement something like that myself. The solution
>>>>> with the "StartupIndicator"-services makes it easier to maintain because
>>>>> I can describe the conditions to be met in the corresponding bundle
>>>>> (which I reuse in several assemblies).
>>>>> I could create an additional bundle querying those services and delay
>>>>> the console with the right use of start-levels.
>>>>> 
>>>>> But at some points a tighter integration into karaf would be nice (like
>>>>> the FeatureService).
>>>>> 
>>>>> kind regards,
>>>>> christoph
>>>>> 
>>>>> 
>>>>> On 09/08/12 13:59, Christian Schneider wrote:
>>>>> 
>>>>>> 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 <gn...@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é
>>>>>>>>> <jb@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é
>>>>>>>>>>> <jb...@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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Charles Moulliard
>>> Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>> Twitter : @cmoulliard
>>> Blog : http://cmoulliard.blogspot.com
>> 
>> 
>> 
>> --
>> 
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer & Project Lead
>> OPS4J Pax for Vaadin
>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>> Lead
>> blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by Freeman Fang <fr...@gmail.com>.
Fully agree.

Freeman
－－－－－－－－－－－－－
Freeman Fang

FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042

On 2012-8-10, at 上午12:43, Andreas Pieber wrote:

> After reading the entire thread again I think we've got our wires
> crossed. The entire point is NOT (!) to make Karaf waiting for
> anything to start up per default; I second Christoph at this point: I
> think it's best if the default Karaf download works exactly as it does
> in the 2.2.x branch: getting the console up as fast as possible.
> Independently, most of us had been confronted by one or the other
> customer/partner, ... "When can I access my services"; typically I
> just want to stand up in such situations, punch their faces and tell
> them "once they work, they're ready"... Well, since those are my/our
> customers this might not be the best solution. And this is where
> Christians approach comes in handy: hide the console by default till
> everything "is ready". As mentioned now by various ppl already: when
> is the system ready; well, as JB said, Karaf as a small and neat
> container does not have to find out; this is (IMHO) nothing we can
> solve usefully at a central place for all and everything, BUT we can
> solve it for our customers and their/our custom distributions by e.g.
> placing a bundle doing all the logic and simply saying when Karaf is
> ready.
> 
> So, back to the requirements; what do we need
> 
> a) per default nothing than we have now
> b) if we deliver a distribution it would be nice if we can switch a
> flag and the karaf console wont appear till my bundle says that its
> ready
> 
> Basically Christians/Guillaume algorithms are almost enough for this:
> once all bundles are active they had the chance to register a
> "ReadService" via the activator. Waiting that those also get active
> should be almost enough: why? Because my typical customer/project
> partner has no real chance to find any errors in those phases on
> himself anyhow --> he'll send me the log if the Shell isn't up in
> 10min --> we don't need to care if those services hang forever.
> NOTHING of this is Karaf business; it would just be nice having some
> extension point to extend the console wait time till I as a
> distribution adapter say that it's ready.
> 
> And just to make it clear another time: I DON'T want to handle camel
> routes, blueprint, cxf or whatever in karaf! We (as Karaf) don't care
> about:
> 
> "- when the application server itself is up and running ?
> - when the resources in the application server are up (datasource, JMS
> server, etc) ?
> - when the applications are started ?"
> 
> For Karaf it's not relevant which of those things hide behind the
> "ReadyServices"; we don't implement them! We just wait till all
> registered "ReadyServices" say go and start the shell then; nothing
> more and nothing less, just give distribution adapters a tool to
> satisfy their customers :-)
> 
> I hope I was able to clear up things a little bit,
> Kind regards,
> Andreas
> 
> On Thu, Aug 9, 2012 at 5:44 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
>> @Charles, JB
>> 
>> I fully agree with you, where is the line to be drawn here?
>> 
>> Well anyone who is developing with Karaf should know it's a totally
>> different way of working instead of using a bloated JEE-Container.
>> This discussion somehow reminds me of a thread I once read on the
>> felix-ml "I don't want to develop OSGi I just want to use it".
>> 
>> As far as I'm concerned you shouldn't "Develop" OSGi but you have to
>> get used to some constraints and projecting those to Karaf it's like
>> this, if the container is running you have a shell but it doesn't say
>> you application is running.
>> The bad thing about it is, all those people are used to live without,
>> neither JBoss nor Tomcat provide a shell.
>> Oh wait they do, it's just the std. plain HTML stuff and guess what
>> sometimes the std. wars are already up and running but your own isn't.
>> Now what are we expecting of Tomcat to do? Is tomcat supposed to serve
>> no content unless all wars are up an running?
>> People just got used to slow running Web-applications that they don't
>> feel comfortable when beeing able to work faster it seems ...
>> 
>> again just my 2 cents
>> 
>> regards, Achim
>> 
>> 2012/8/9 Charles Moulliard <ch...@gmail.com>:
>>> Well said JB. This is exactly what I have explained this morning.
>>> 
>>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I'm not fully agree.
>>>> 
>>>> Karaf is a container, with the purpose to be fast, lightweight.
>>>> So what does it mean "Karaf started" ?
>>>> 
>>>> For instance, I gonna compare with JEE application server. When do you
>>>> consider that an application server is started:
>>>> - when the application server itself is up and running ?
>>>> - when the resources in the application server are up (datasource, JMS
>>>> server, etc) ?
>>>> - when the applications are started ?
>>>> 
>>>> All is question of perspective.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>> 
>>>> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>>>> 
>>>>> I understand that when using karaf as a developer one would want the
>>>>> shell as fast as possible and don't wait for a minute or something.
>>>>> That's why Christian implemented the "Press Enter to start it
>>>>> anyway"-thing I think.
>>>>> Maybe it's a better option to make it optional after all and disable it
>>>>> in the karaf-distributions, but allowing users to modify some
>>>>> config-file to get the delayed-console-startup.
>>>>> This way developers are not annoyed by long startup-times, but
>>>>> karaf-based products could provide the user with proper feedback.
>>>>> 
>>>>> And about the uptime vs startup time: I agree with Christian here. But
>>>>> we have a customer who develops his own external systems that interact
>>>>> with our karaf-based application. Their developers complained, they
>>>>> can't tell when karaf is started, and they need to start and stop it
>>>>> more often during development, but don't really want to get into karaf
>>>>> to deeply because it's just an external system.
>>>>> 
>>>>> I could also try to implement something like that myself. The solution
>>>>> with the "StartupIndicator"-services makes it easier to maintain because
>>>>> I can describe the conditions to be met in the corresponding bundle
>>>>> (which I reuse in several assemblies).
>>>>> I could create an additional bundle querying those services and delay
>>>>> the console with the right use of start-levels.
>>>>> 
>>>>> But at some points a tighter integration into karaf would be nice (like
>>>>> the FeatureService).
>>>>> 
>>>>> kind regards,
>>>>> christoph
>>>>> 
>>>>> 
>>>>> On 09/08/12 13:59, Christian Schneider wrote:
>>>>> 
>>>>>> 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 <gn...@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é
>>>>>>>>> <jb@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é
>>>>>>>>>>> <jb...@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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Charles Moulliard
>>> Apache Committer / Sr. Pr. Consultant at FuseSource.com
>>> Twitter : @cmoulliard
>>> Blog : http://cmoulliard.blogspot.com
>> 
>> 
>> 
>> --
>> 
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer & Project Lead
>> OPS4J Pax for Vaadin
>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>> Lead
>> blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by Andreas Pieber <an...@gmail.com>.
After reading the entire thread again I think we've got our wires
crossed. The entire point is NOT (!) to make Karaf waiting for
anything to start up per default; I second Christoph at this point: I
think it's best if the default Karaf download works exactly as it does
in the 2.2.x branch: getting the console up as fast as possible.
Independently, most of us had been confronted by one or the other
customer/partner, ... "When can I access my services"; typically I
just want to stand up in such situations, punch their faces and tell
them "once they work, they're ready"... Well, since those are my/our
customers this might not be the best solution. And this is where
Christians approach comes in handy: hide the console by default till
everything "is ready". As mentioned now by various ppl already: when
is the system ready; well, as JB said, Karaf as a small and neat
container does not have to find out; this is (IMHO) nothing we can
solve usefully at a central place for all and everything, BUT we can
solve it for our customers and their/our custom distributions by e.g.
placing a bundle doing all the logic and simply saying when Karaf is
ready.

So, back to the requirements; what do we need

a) per default nothing than we have now
b) if we deliver a distribution it would be nice if we can switch a
flag and the karaf console wont appear till my bundle says that its
ready

Basically Christians/Guillaume algorithms are almost enough for this:
once all bundles are active they had the chance to register a
"ReadService" via the activator. Waiting that those also get active
should be almost enough: why? Because my typical customer/project
partner has no real chance to find any errors in those phases on
himself anyhow --> he'll send me the log if the Shell isn't up in
10min --> we don't need to care if those services hang forever.
NOTHING of this is Karaf business; it would just be nice having some
extension point to extend the console wait time till I as a
distribution adapter say that it's ready.

And just to make it clear another time: I DON'T want to handle camel
routes, blueprint, cxf or whatever in karaf! We (as Karaf) don't care
about:

"- when the application server itself is up and running ?
- when the resources in the application server are up (datasource, JMS
server, etc) ?
- when the applications are started ?"

For Karaf it's not relevant which of those things hide behind the
"ReadyServices"; we don't implement them! We just wait till all
registered "ReadyServices" say go and start the shell then; nothing
more and nothing less, just give distribution adapters a tool to
satisfy their customers :-)

I hope I was able to clear up things a little bit,
Kind regards,
Andreas

On Thu, Aug 9, 2012 at 5:44 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
> @Charles, JB
>
> I fully agree with you, where is the line to be drawn here?
>
> Well anyone who is developing with Karaf should know it's a totally
> different way of working instead of using a bloated JEE-Container.
> This discussion somehow reminds me of a thread I once read on the
> felix-ml "I don't want to develop OSGi I just want to use it".
>
> As far as I'm concerned you shouldn't "Develop" OSGi but you have to
> get used to some constraints and projecting those to Karaf it's like
> this, if the container is running you have a shell but it doesn't say
> you application is running.
> The bad thing about it is, all those people are used to live without,
> neither JBoss nor Tomcat provide a shell.
> Oh wait they do, it's just the std. plain HTML stuff and guess what
> sometimes the std. wars are already up and running but your own isn't.
> Now what are we expecting of Tomcat to do? Is tomcat supposed to serve
> no content unless all wars are up an running?
> People just got used to slow running Web-applications that they don't
> feel comfortable when beeing able to work faster it seems ...
>
> again just my 2 cents
>
> regards, Achim
>
> 2012/8/9 Charles Moulliard <ch...@gmail.com>:
>> Well said JB. This is exactly what I have explained this morning.
>>
>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>>
>>> Hi,
>>>
>>> I'm not fully agree.
>>>
>>> Karaf is a container, with the purpose to be fast, lightweight.
>>> So what does it mean "Karaf started" ?
>>>
>>> For instance, I gonna compare with JEE application server. When do you
>>> consider that an application server is started:
>>> - when the application server itself is up and running ?
>>> - when the resources in the application server are up (datasource, JMS
>>> server, etc) ?
>>> - when the applications are started ?
>>>
>>> All is question of perspective.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>>>
>>>> I understand that when using karaf as a developer one would want the
>>>> shell as fast as possible and don't wait for a minute or something.
>>>> That's why Christian implemented the "Press Enter to start it
>>>> anyway"-thing I think.
>>>> Maybe it's a better option to make it optional after all and disable it
>>>> in the karaf-distributions, but allowing users to modify some
>>>> config-file to get the delayed-console-startup.
>>>> This way developers are not annoyed by long startup-times, but
>>>> karaf-based products could provide the user with proper feedback.
>>>>
>>>> And about the uptime vs startup time: I agree with Christian here. But
>>>> we have a customer who develops his own external systems that interact
>>>> with our karaf-based application. Their developers complained, they
>>>> can't tell when karaf is started, and they need to start and stop it
>>>> more often during development, but don't really want to get into karaf
>>>> to deeply because it's just an external system.
>>>>
>>>> I could also try to implement something like that myself. The solution
>>>> with the "StartupIndicator"-services makes it easier to maintain because
>>>> I can describe the conditions to be met in the corresponding bundle
>>>> (which I reuse in several assemblies).
>>>> I could create an additional bundle querying those services and delay
>>>> the console with the right use of start-levels.
>>>>
>>>> But at some points a tighter integration into karaf would be nice (like
>>>> the FeatureService).
>>>>
>>>> kind regards,
>>>> christoph
>>>>
>>>>
>>>> On 09/08/12 13:59, Christian Schneider wrote:
>>>>
>>>>> 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 <gn...@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é
>>>>>>>> <jb@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é
>>>>>>>>>> <jb...@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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> Charles Moulliard
>> Apache Committer / Sr. Pr. Consultant at FuseSource.com
>> Twitter : @cmoulliard
>> Blog : http://cmoulliard.blogspot.com
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> OPS4J Pax for Vaadin
> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
> Lead
> blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by Achim Nierbeck <bc...@googlemail.com>.
@Charles, JB

I fully agree with you, where is the line to be drawn here?

Well anyone who is developing with Karaf should know it's a totally
different way of working instead of using a bloated JEE-Container.
This discussion somehow reminds me of a thread I once read on the
felix-ml "I don't want to develop OSGi I just want to use it".

As far as I'm concerned you shouldn't "Develop" OSGi but you have to
get used to some constraints and projecting those to Karaf it's like
this, if the container is running you have a shell but it doesn't say
you application is running.
The bad thing about it is, all those people are used to live without,
neither JBoss nor Tomcat provide a shell.
Oh wait they do, it's just the std. plain HTML stuff and guess what
sometimes the std. wars are already up and running but your own isn't.
Now what are we expecting of Tomcat to do? Is tomcat supposed to serve
no content unless all wars are up an running?
People just got used to slow running Web-applications that they don't
feel comfortable when beeing able to work faster it seems ...

again just my 2 cents

regards, Achim

2012/8/9 Charles Moulliard <ch...@gmail.com>:
> Well said JB. This is exactly what I have explained this morning.
>
> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
>
>> Hi,
>>
>> I'm not fully agree.
>>
>> Karaf is a container, with the purpose to be fast, lightweight.
>> So what does it mean "Karaf started" ?
>>
>> For instance, I gonna compare with JEE application server. When do you
>> consider that an application server is started:
>> - when the application server itself is up and running ?
>> - when the resources in the application server are up (datasource, JMS
>> server, etc) ?
>> - when the applications are started ?
>>
>> All is question of perspective.
>>
>> Regards
>> JB
>>
>>
>> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>>
>>> I understand that when using karaf as a developer one would want the
>>> shell as fast as possible and don't wait for a minute or something.
>>> That's why Christian implemented the "Press Enter to start it
>>> anyway"-thing I think.
>>> Maybe it's a better option to make it optional after all and disable it
>>> in the karaf-distributions, but allowing users to modify some
>>> config-file to get the delayed-console-startup.
>>> This way developers are not annoyed by long startup-times, but
>>> karaf-based products could provide the user with proper feedback.
>>>
>>> And about the uptime vs startup time: I agree with Christian here. But
>>> we have a customer who develops his own external systems that interact
>>> with our karaf-based application. Their developers complained, they
>>> can't tell when karaf is started, and they need to start and stop it
>>> more often during development, but don't really want to get into karaf
>>> to deeply because it's just an external system.
>>>
>>> I could also try to implement something like that myself. The solution
>>> with the "StartupIndicator"-services makes it easier to maintain because
>>> I can describe the conditions to be met in the corresponding bundle
>>> (which I reuse in several assemblies).
>>> I could create an additional bundle querying those services and delay
>>> the console with the right use of start-levels.
>>>
>>> But at some points a tighter integration into karaf would be nice (like
>>> the FeatureService).
>>>
>>> kind regards,
>>> christoph
>>>
>>>
>>> On 09/08/12 13:59, Christian Schneider wrote:
>>>
>>>> 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 <gn...@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é
>>>>>>> <jb@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é
>>>>>>>>> <jb...@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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Pr. Consultant at FuseSource.com
> Twitter : @cmoulliard
> Blog : http://cmoulliard.blogspot.com



-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by Charles Moulliard <ch...@gmail.com>.
Well said JB. This is exactly what I have explained this morning.

On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:

> Hi,
>
> I'm not fully agree.
>
> Karaf is a container, with the purpose to be fast, lightweight.
> So what does it mean "Karaf started" ?
>
> For instance, I gonna compare with JEE application server. When do you
> consider that an application server is started:
> - when the application server itself is up and running ?
> - when the resources in the application server are up (datasource, JMS
> server, etc) ?
> - when the applications are started ?
>
> All is question of perspective.
>
> Regards
> JB
>
>
> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>
>> I understand that when using karaf as a developer one would want the
>> shell as fast as possible and don't wait for a minute or something.
>> That's why Christian implemented the "Press Enter to start it
>> anyway"-thing I think.
>> Maybe it's a better option to make it optional after all and disable it
>> in the karaf-distributions, but allowing users to modify some
>> config-file to get the delayed-console-startup.
>> This way developers are not annoyed by long startup-times, but
>> karaf-based products could provide the user with proper feedback.
>>
>> And about the uptime vs startup time: I agree with Christian here. But
>> we have a customer who develops his own external systems that interact
>> with our karaf-based application. Their developers complained, they
>> can't tell when karaf is started, and they need to start and stop it
>> more often during development, but don't really want to get into karaf
>> to deeply because it's just an external system.
>>
>> I could also try to implement something like that myself. The solution
>> with the "StartupIndicator"-services makes it easier to maintain because
>> I can describe the conditions to be met in the corresponding bundle
>> (which I reuse in several assemblies).
>> I could create an additional bundle querying those services and delay
>> the console with the right use of start-levels.
>>
>> But at some points a tighter integration into karaf would be nice (like
>> the FeatureService).
>>
>> kind regards,
>> christoph
>>
>>
>> On 09/08/12 13:59, Christian Schneider wrote:
>>
>>> 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 <gn...@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é
>>>>>> <jb@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é
>>>>>>>> <jb...@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
>>>>>
>>>>
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
Charles Moulliard
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Twitter : @cmoulliard
Blog : http://cmoulliard.blogspot.com

Re: Telling whether startup is really complete

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,

I'm not fully agree.

Karaf is a container, with the purpose to be fast, lightweight.
So what does it mean "Karaf started" ?

For instance, I gonna compare with JEE application server. When do you 
consider that an application server is started:
- when the application server itself is up and running ?
- when the resources in the application server are up (datasource, JMS 
server, etc) ?
- when the applications are started ?

All is question of perspective.

Regards
JB

On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
> I understand that when using karaf as a developer one would want the
> shell as fast as possible and don't wait for a minute or something.
> That's why Christian implemented the "Press Enter to start it
> anyway"-thing I think.
> Maybe it's a better option to make it optional after all and disable it
> in the karaf-distributions, but allowing users to modify some
> config-file to get the delayed-console-startup.
> This way developers are not annoyed by long startup-times, but
> karaf-based products could provide the user with proper feedback.
>
> And about the uptime vs startup time: I agree with Christian here. But
> we have a customer who develops his own external systems that interact
> with our karaf-based application. Their developers complained, they
> can't tell when karaf is started, and they need to start and stop it
> more often during development, but don't really want to get into karaf
> to deeply because it's just an external system.
>
> I could also try to implement something like that myself. The solution
> with the "StartupIndicator"-services makes it easier to maintain because
> I can describe the conditions to be met in the corresponding bundle
> (which I reuse in several assemblies).
> I could create an additional bundle querying those services and delay
> the console with the right use of start-levels.
>
> But at some points a tighter integration into karaf would be nice (like
> the FeatureService).
>
> kind regards,
> christoph
>
>
> On 09/08/12 13:59, Christian Schneider wrote:
>> 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 <gn...@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é
>>>>> <jb@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é
>>>>>>> <jb...@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
>>
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Telling whether startup is really complete

Posted by Christoph Gritschenberger <ch...@gmail.com>.
I understand that when using karaf as a developer one would want the
shell as fast as possible and don't wait for a minute or something.
That's why Christian implemented the "Press Enter to start it
anyway"-thing I think.
Maybe it's a better option to make it optional after all and disable it
in the karaf-distributions, but allowing users to modify some
config-file to get the delayed-console-startup.
This way developers are not annoyed by long startup-times, but
karaf-based products could provide the user with proper feedback.

And about the uptime vs startup time: I agree with Christian here. But
we have a customer who develops his own external systems that interact
with our karaf-based application. Their developers complained, they
can't tell when karaf is started, and they need to start and stop it
more often during development, but don't really want to get into karaf
to deeply because it's just an external system.

I could also try to implement something like that myself. The solution
with the "StartupIndicator"-services makes it easier to maintain because
I can describe the conditions to be met in the corresponding bundle
(which I reuse in several assemblies).
I could create an additional bundle querying those services and delay
the console with the right use of start-levels.

But at some points a tighter integration into karaf would be nice (like
the FeatureService).

kind regards,
christoph


On 09/08/12 13:59, Christian Schneider wrote:
> 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 <gn...@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é
>>>> <jb@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é
>>>>>> <jb...@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
> 
>

Re: Telling whether startup is really complete

Posted by Christian Schneider <ch...@die-schneider.net>.
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 <gn...@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é <jb@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é <jb...@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

Re: Telling whether startup is really complete

Posted by Johan Edstrom <se...@gmail.com>.
+2 pence.

On Aug 9, 2012, at 5:26 AM, Achim Nierbeck wrote:

> Hi,
> 
> I have to second Jamie on this, cause right now I'm quite happy with
> having a shell right away so
> if I'm really in need for knowing if all bundles are up and runnig
> I'll do a "la" and I'm fine knowing how it's proceeding.
> For me there is no real need to hide the shell from users, cause let's
> take a look on how long is a Server process supposed to run
> at best forever or the time the machine dies. So basically it'll have
> the same up-time as the machine which will be longer on
> linux then on windows. Compared to the uptime the time it takes to
> load the complete set of bundles (if it's about a 100) is about 3
> minutes (worst case).
> Now  3 / infinity = 0 so I don't see a point of making so much fuzz
> about a 3 minutes window for starting a fresh karaf (a reboot is
> always much faster).
> For knowing if my application is around I'm with charles to say, hey
> use JMX to monitor your application. There are plenty of Nexus
> connectors around to monitor
> any application with JMX.
> 
> Just my 2 cents here ...
> 
> regards, Achim
> 
> 2012/8/9 Jamie G. <ja...@gmail.com>:
>> 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 <gn...@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é <jb@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é <jb...@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
> 
> 
> 
> -- 
> 
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> OPS4J Pax for Vaadin
> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
> Lead
> blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,

I have to second Jamie on this, cause right now I'm quite happy with
having a shell right away so
if I'm really in need for knowing if all bundles are up and runnig
I'll do a "la" and I'm fine knowing how it's proceeding.
For me there is no real need to hide the shell from users, cause let's
take a look on how long is a Server process supposed to run
at best forever or the time the machine dies. So basically it'll have
the same up-time as the machine which will be longer on
linux then on windows. Compared to the uptime the time it takes to
load the complete set of bundles (if it's about a 100) is about 3
minutes (worst case).
Now  3 / infinity = 0 so I don't see a point of making so much fuzz
about a 3 minutes window for starting a fresh karaf (a reboot is
always much faster).
For knowing if my application is around I'm with charles to say, hey
use JMX to monitor your application. There are plenty of Nexus
connectors around to monitor
any application with JMX.

Just my 2 cents here ...

regards, Achim

2012/8/9 Jamie G. <ja...@gmail.com>:
> 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 <gn...@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é <jb@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é <jb...@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



-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>

Re: Telling whether startup is really complete

Posted by "Jamie G." <ja...@gmail.com>.
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 <gn...@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é <jb@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é <jb...@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

Re: Telling whether startup is really complete

Posted by Guillaume Nodet <gn...@gmail.com>.
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é <jb@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é <jb...@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

Re: Telling whether startup is really complete

Posted by Andreas Pieber <an...@gmail.com>.
Hey JB,

On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> 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é <jb...@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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Telling whether startup is really complete

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Telling whether startup is really complete

Posted by Andreas Pieber <an...@gmail.com>.
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é <jb...@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Telling whether startup is really complete

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Telling whether startup is really complete

Posted by Christian Schneider <ch...@die-schneider.net>.
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

Re: Telling whether startup is really complete

Posted by Prithviraj <me...@gmail.com>.
Thanks a lot JB .

Thanks,
Prithvi

On Mon, Dec 22, 2014 at 8:53 PM, jbonofre [via Karaf] <
ml-node+s922171n4037362h26@n3.nabble.com> wrote:

> You can create a script (in Karaf) that you use with bin/client (with
> shell:source for instance).
>
> For instance, something like:
>
> bundles = bundle:list -t 0; each ($bundles) { if { $state equals
> "Active" } echo $state }
>
> or so.
>
> Regards
> JB
>
> On 12/22/2014 03:38 PM, Prithviraj wrote:
>
> > Hi JB ,
> >
> > I tried this too , but   by this  way  it is giving current  state  of
>  all
> > bundles .
> > Is  there any api  which  can  direct  give  me this as output ?
> > i think StartupListener.java  class  from karaf jar  implemented  same
> >   thing.
> > how i can invoke it from script   ?
> >
> > Thanks,
> > Prithvi
> >
> > On Mon, Dec 22, 2014 at 7:51 PM, jbonofre [via Karaf] <
> > [hidden email] <http:///user/SendEmail.jtp?type=node&node=4037362&i=0>>
> wrote:
> >
> >> Hi
> >>
> >> 1/ the bin/start script does exactly as your script
> >> 2/ use bin/client script to execute bundle:list -t 0 and check (with a
> >> regex) that all bundles are in started state.
> >>
> >> Regards
> >> JB
> >>
> >>
> >> -------- Original message --------
> >> From: Prithviraj <[hidden email]
> >> <http:///user/SendEmail.jtp?type=node&node=4037360&i=0>>
> >> Date:22/12/2014  14:14  (GMT+01:00)
> >> To: [hidden email] <
> http:///user/SendEmail.jtp?type=node&node=4037360&i=1>
> >> Cc:
> >> Subject: Re: Telling whether startup is really complete
> >>
> >> Hi JB,
> >>
> >> I tried this , it displayed the message as mentioned in
> custom.properties
> >> file .
> >> Actually it is not solving my problem .
> >> My problem statement is like below
> >> 1) I have  wrote start_karaf.sh file  which will invoke start  script
> >>   from
> >> {$KARAF_HOME}/bin location .
> >> Which internally start the karaf in back ground mode
> >> 2) I have other script deploy_apps.sh which will get execute  once
> >>   previous
> >> start_karaf.sh  script get successfully executed.
> >> deploy_app.sh script is for  deploying  bundles in karaf  server.
> >> Since  start_karaf.sh  invoking karaf server in background , i need to
> >> know
> >> if  server is fully started  before  deploying apps .
> >> So i need  some mechanism , or  commands  by which i  can come to know
> >> server is  fully started  so  that i can start with bundle app
> deployment
> >> .
> >>
> >> Thanks in advance  for your help .
> >>
> >> Thanks
> >> Prithvi
> >>
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037359.html
> >> Sent from the Karaf - Dev mailing list archive at Nabble.com.
> >>
> >>
> >> ------------------------------
> >>   If you reply to this email, your message will be added to the
> discussion
> >> below:
> >>
> >>
> http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037360.html
> >>   To unsubscribe from Telling whether startup is really complete, click
> >> here
> >> <
> >> .
> >> NAML
> >> <
> http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
> >>
> >
> >
> >
> >
> > --
> > View this message in context:
> http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037361.html
> > Sent from the Karaf - Dev mailing list archive at Nabble.com.
> >
>
> --
> Jean-Baptiste Onofré
> [hidden email] <http:///user/SendEmail.jtp?type=node&node=4037362&i=1>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037362.html
>  To unsubscribe from Telling whether startup is really complete, click
> here
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4025451&code=bWVldHJhajE0QGdtYWlsLmNvbXw0MDI1NDUxfC0yMDU1MjgzMDg0>
> .
> NAML
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037408.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.

Re: Telling whether startup is really complete

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
You can create a script (in Karaf) that you use with bin/client (with 
shell:source for instance).

For instance, something like:

bundles = bundle:list -t 0; each ($bundles) { if { $state equals 
"Active" } echo $state }

or so.

Regards
JB

On 12/22/2014 03:38 PM, Prithviraj wrote:
> Hi JB ,
>
> I tried this too , but   by this  way  it is giving current  state  of  all
> bundles .
> Is  there any api  which  can  direct  give  me this as output ?
> i think StartupListener.java  class  from karaf jar  implemented  same
>   thing.
> how i can invoke it from script   ?
>
> Thanks,
> Prithvi
>
> On Mon, Dec 22, 2014 at 7:51 PM, jbonofre [via Karaf] <
> ml-node+s922171n4037360h64@n3.nabble.com> wrote:
>
>> Hi
>>
>> 1/ the bin/start script does exactly as your script
>> 2/ use bin/client script to execute bundle:list -t 0 and check (with a
>> regex) that all bundles are in started state.
>>
>> Regards
>> JB
>>
>>
>> -------- Original message --------
>> From: Prithviraj <[hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=4037360&i=0>>
>> Date:22/12/2014  14:14  (GMT+01:00)
>> To: [hidden email] <http:///user/SendEmail.jtp?type=node&node=4037360&i=1>
>> Cc:
>> Subject: Re: Telling whether startup is really complete
>>
>> Hi JB,
>>
>> I tried this , it displayed the message as mentioned in custom.properties
>> file .
>> Actually it is not solving my problem .
>> My problem statement is like below
>> 1) I have  wrote start_karaf.sh file  which will invoke start  script
>>   from
>> {$KARAF_HOME}/bin location .
>> Which internally start the karaf in back ground mode
>> 2) I have other script deploy_apps.sh which will get execute  once
>>   previous
>> start_karaf.sh  script get successfully executed.
>> deploy_app.sh script is for  deploying  bundles in karaf  server.
>> Since  start_karaf.sh  invoking karaf server in background , i need to
>> know
>> if  server is fully started  before  deploying apps .
>> So i need  some mechanism , or  commands  by which i  can come to know
>> server is  fully started  so  that i can start with bundle app deployment
>> .
>>
>> Thanks in advance  for your help .
>>
>> Thanks
>> Prithvi
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037359.html
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
>>
>> ------------------------------
>>   If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037360.html
>>   To unsubscribe from Telling whether startup is really complete, click
>> here
>> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4025451&code=bWVldHJhajE0QGdtYWlsLmNvbXw0MDI1NDUxfC0yMDU1MjgzMDg0>
>> .
>> NAML
>> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037361.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Telling whether startup is really complete

Posted by Prithviraj <me...@gmail.com>.
Hi JB ,

I tried this too , but   by this  way  it is giving current  state  of  all
bundles .
Is  there any api  which  can  direct  give  me this as output ?
i think StartupListener.java  class  from karaf jar  implemented  same
 thing.
how i can invoke it from script   ?

Thanks,
Prithvi

On Mon, Dec 22, 2014 at 7:51 PM, jbonofre [via Karaf] <
ml-node+s922171n4037360h64@n3.nabble.com> wrote:

> Hi
>
> 1/ the bin/start script does exactly as your script
> 2/ use bin/client script to execute bundle:list -t 0 and check (with a
> regex) that all bundles are in started state.
>
> Regards
> JB
>
>
> -------- Original message --------
> From: Prithviraj <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4037360&i=0>>
> Date:22/12/2014  14:14  (GMT+01:00)
> To: [hidden email] <http:///user/SendEmail.jtp?type=node&node=4037360&i=1>
> Cc:
> Subject: Re: Telling whether startup is really complete
>
> Hi JB,
>
> I tried this , it displayed the message as mentioned in custom.properties
> file .
> Actually it is not solving my problem .
> My problem statement is like below
> 1) I have  wrote start_karaf.sh file  which will invoke start  script
>  from
> {$KARAF_HOME}/bin location .
> Which internally start the karaf in back ground mode
> 2) I have other script deploy_apps.sh which will get execute  once
>  previous
> start_karaf.sh  script get successfully executed.
> deploy_app.sh script is for  deploying  bundles in karaf  server.
> Since  start_karaf.sh  invoking karaf server in background , i need to
> know
> if  server is fully started  before  deploying apps .
> So i need  some mechanism , or  commands  by which i  can come to know
> server is  fully started  so  that i can start with bundle app deployment
> .
>
> Thanks in advance  for your help .
>
> Thanks
> Prithvi
>
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037359.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037360.html
>  To unsubscribe from Telling whether startup is really complete, click
> here
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4025451&code=bWVldHJhajE0QGdtYWlsLmNvbXw0MDI1NDUxfC0yMDU1MjgzMDg0>
> .
> NAML
> <http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://karaf.922171.n3.nabble.com/Telling-whether-startup-is-really-complete-tp4025451p4037361.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.