Re: Telling whether startup is really complete

[Christian Schneider]

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: svn commit: r1371394 - /karaf/karaf/

[Achim Nierbeck]

yeah, thanks for the pointers, just with windows command-line is also
pita ... :/

2012/8/10 Freeman Fang :
> +1, the command line is more reliable in this case :-)
> －
> Freeman Fang
>
> FuseSource
> Email:ff...@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 上午4:34, Andreas Pieber wrote:
>
>> see, that's the reason why I never ever let go of my console and give
>> the commit/push control to some ide toolings. command shell FTW :-D
>>
>> On Thu, Aug 9, 2012 at 9:21 PM, Achim Nierbeck  
>> wrote:
>>> WTF, what happend here, just tried to get a disconnected repo
>>> connected again, sorry for this mess :/
>>>
>>> I'll try to take care of it stupid eclipse 
>>>
>>> regards, Achim
>>>
>>> 2012/8/9  :
 Author: anierbeck
 Date: Thu Aug  9 19:18:19 2012
 New Revision: 1371394

 URL: http://svn.apache.org/viewvc?rev=1371394&view=rev
 Log:
 Share project "karaf" into "https://svn.apache.org/repos/asf/karaf";

 Added:
karaf/karaf/

>>>
>>>
>>>
>>> --
>>>
>>> Apache Karaf  Committer & PMC
>>> OPS4J Pax Web 
>>> Committer & Project Lead
>>> OPS4J Pax for Vaadin
>>>  Commiter & Project
>>> Lead
>>> blog 
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web 
Committer & Project Lead
OPS4J Pax for Vaadin
 Commiter & Project
Lead
blog 

Re: Telling whether startup is really complete

[Freeman Fang]

Fully agree.

Freeman
－
Freeman Fang

FuseSource
Email:ff...@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  
> 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 :
>>> Well said JB. This is exactly what I have explained this morning.
>>> 
>>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré 
>>> 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

Re: svn commit: r1371394 - /karaf/karaf/

[Freeman Fang]

+1, the command line is more reliable in this case :-)
－
Freeman Fang

FuseSource
Email:ff...@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 上午4:34, Andreas Pieber wrote:

> see, that's the reason why I never ever let go of my console and give
> the commit/push control to some ide toolings. command shell FTW :-D
> 
> On Thu, Aug 9, 2012 at 9:21 PM, Achim Nierbeck  
> wrote:
>> WTF, what happend here, just tried to get a disconnected repo
>> connected again, sorry for this mess :/
>> 
>> I'll try to take care of it stupid eclipse 
>> 
>> regards, Achim
>> 
>> 2012/8/9  :
>>> Author: anierbeck
>>> Date: Thu Aug  9 19:18:19 2012
>>> New Revision: 1371394
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1371394&view=rev
>>> Log:
>>> Share project "karaf" into "https://svn.apache.org/repos/asf/karaf";
>>> 
>>> Added:
>>>karaf/karaf/
>>> 
>> 
>> 
>> 
>> --
>> 
>> Apache Karaf  Committer & PMC
>> OPS4J Pax Web 
>> Committer & Project Lead
>> OPS4J Pax for Vaadin
>>  Commiter & Project
>> Lead
>> blog 

Re: svn commit: r1371394 - /karaf/karaf/

[Andreas Pieber]

see, that's the reason why I never ever let go of my console and give
the commit/push control to some ide toolings. command shell FTW :-D

On Thu, Aug 9, 2012 at 9:21 PM, Achim Nierbeck  wrote:
> WTF, what happend here, just tried to get a disconnected repo
> connected again, sorry for this mess :/
>
> I'll try to take care of it stupid eclipse 
>
> regards, Achim
>
> 2012/8/9  :
>> Author: anierbeck
>> Date: Thu Aug  9 19:18:19 2012
>> New Revision: 1371394
>>
>> URL: http://svn.apache.org/viewvc?rev=1371394&view=rev
>> Log:
>> Share project "karaf" into "https://svn.apache.org/repos/asf/karaf";
>>
>> Added:
>> karaf/karaf/
>>
>
>
>
> --
>
> Apache Karaf  Committer & PMC
> OPS4J Pax Web 
> Committer & Project Lead
> OPS4J Pax for Vaadin
>  Commiter & Project
> Lead
> blog 

Re: svn commit: r1371394 - /karaf/karaf/

[Achim Nierbeck]

WTF, what happend here, just tried to get a disconnected repo
connected again, sorry for this mess :/

I'll try to take care of it stupid eclipse 

regards, Achim

2012/8/9  :
> Author: anierbeck
> Date: Thu Aug  9 19:18:19 2012
> New Revision: 1371394
>
> URL: http://svn.apache.org/viewvc?rev=1371394&view=rev
> Log:
> Share project "karaf" into "https://svn.apache.org/repos/asf/karaf";
>
> Added:
> karaf/karaf/
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web 
Committer & Project Lead
OPS4J Pax for Vaadin
 Commiter & Project
Lead
blog 

Re: Telling whether startup is really complete

[Achim Nierbeck]

+1

2012/8/9 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
>>
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web 
Committer & Project Lead
OPS4J Pax for Vaadin
 Commiter & Project
Lead
blog 

Re: Telling whether startup is really complete

[Achim Nierbeck]

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 :
> 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  Committer & PMC
OPS4J Pax Web 
Committer & Project Lead
OPS4J Pax for Vaadin
 Commiter & Project
Lead
blog 

Re: Telling whether startup is really complete

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

Re: Telling whether startup is really complete

[Christian Schneider]

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

[Andreas Pieber]

nicely summed up; +1 :-)

Kind regards,
Andreas

On Thu, Aug 9, 2012 at 7:40 PM, Ioannis Canellos  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 
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Twitter: iocanel
> *

Re: Telling whether startup is really complete

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

-- 
*Ioannis Canellos*
*
FuseSource 

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

Re: Telling whether startup is really complete

[Andreas Pieber]

what do you mean?

Kind regards,
Andreas

On Thu, Aug 9, 2012 at 6:45 PM, Johan Edstrom  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  
>> 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 :
 Well said JB. This is exactly what I have explained this morning.

 On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré 
 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 th

Re: Telling whether startup is really complete

[Johan Edstrom]

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  
> 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 :
>>> Well said JB. This is exactly what I have explained this morning.
>>> 
>>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré 
>>> 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 

Re: Telling whether startup is really complete

[Andreas Pieber]

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  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 :
>> Well said JB. This is exactly what I have explained this morning.
>>
>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré 
>> 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

Re: Telling whether startup is really complete

[Achim Nierbeck]

@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 :
> Well said JB. This is exactly what I have explained this morning.
>
> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré 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 ce

Re: Telling whether startup is really complete

[Charles Moulliard]

Well said JB. This is exactly what I have explained this morning.

On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré 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 
 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 P

Re: Telling whether startup is really complete

[Jean-Baptiste Onofré]

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

Re: Telling whether startup is really complete

[Christoph Gritschenberger]

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  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é
 >
 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"
 sta

Re: Telling whether startup is really complete

[Christian Schneider]

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

Re: Telling whether startup is really complete

[Johan Edstrom]

+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. :
>> 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  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é 
 >
 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, webap

Re: Telling whether startup is really complete

[Achim Nierbeck]

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. :
> 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  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é 
>>> >
>>> 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.

Re: Telling whether startup is really complete

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

Re: Telling whether startup is really complete

[Guillaume Nodet]

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

Re: Telling whether startup is really complete

[Christian Schneider]

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