Re: Telling whether startup is really complete
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é jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
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.
Re: Telling whether startup is really complete
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 meetra...@gmail.com
Date:22/12/2014 14:14 (GMT+01:00)
To: dev@karaf.apache.org
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.
Re: Telling whether startup is really complete
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+s922171n4037360...@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=nodenode=4037360i=0
Date:22/12/2014 14:14 (GMT+01:00)
To: [hidden email] http:///user/SendEmail.jtp?type=nodenode=4037360i=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_codenode=4025451code=bWVldHJhajE0QGdtYWlsLmNvbXw0MDI1NDUxfC0yMDU1MjgzMDg0
.
NAML
http://karaf.922171.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=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é
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Telling whether startup is really complete
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
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
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Telling whether startup is really complete
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 bcanh...@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 ioca...@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
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 bcanh...@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 ioca...@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
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 anpie...@gmail.com wrote: Hey JB, On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré j...@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é j...@nanthrax.net wrote: Hi Christoph, FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a progress bar while Karaf is starting and the shell console arrives only when the startup is complete. I invite you to take a look on that. Regards JB On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote: Hi, I had another meeting with a customer today who asked me: How can I tell whether it is started up completely?. (It being our karaf-based product) So I had a look at several alternatives how I could accomplish this and had an idea I wanted to discuss. I know that I can modify the Start-level of the Shell-bundle but I don't think that's enough. Recently Christian Schneider implemented something to delay the startup of the shell until all bundles
Re: Telling whether startup is really complete
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é j...@nanthrax.netjavascript:; 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é j...@nanthrax.net wrote: Hi Christoph, FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a progress bar while Karaf is starting and the shell console arrives only when the startup is complete. I invite you to take a look on that. Regards JB On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote: Hi, I had another meeting with a customer today who asked me: How can I tell whether it is started up completely?. (It being our karaf-based product) So I had a look at several alternatives how I could accomplish this and had an idea I wanted to discuss. I know that I can modify the Start-level of the Shell-bundle but I don't think that's enough. Recently Christian Schneider implemented something to delay the startup of the shell until all bundles are active. I think that's a good start, but does not solve the problem completely for me. I encountered several issues with the approach: 1. There is a short delay between the point where all karaf-base-bundles are loaded and the feature-installer starts installing features specified in featuresBoot. When starting up the first time, this almost always happens ... [ 45] [Active]
Re: Telling whether startup is really complete
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 gno...@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é
j...@nanthrax.netjavascript:;
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é j...@nanthrax.net
wrote:
Hi Christoph,
FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a
progress bar while Karaf is starting and the shell console arrives only
when
the startup is complete.
I invite you to take a look on that.
Regards
JB
On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
Hi,
I had another meeting with a customer today who asked me: How can I
tell whether it is started up completely?. (It being our
karaf-based
product)
Re: Telling whether startup is really complete
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. jamie.goody...@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 gno...@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é
j...@nanthrax.netjavascript:;
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.
Re: Telling whether startup is really complete
+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. jamie.goody...@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 gno...@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é
j...@nanthrax.netjavascript:;
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
Re: Telling whether startup is really complete
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 gno...@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é
j...@nanthrax.netjavascript:;
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
Re: Telling whether startup is really complete
Well said JB. This is exactly what I have explained this morning.
On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré j...@nanthrax.netwrote:
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 gno...@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é
j...@nanthrax.netjavascript:;**
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
Re: Telling whether startup is really complete
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 bcanh...@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 ch0...@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é j...@nanthrax.netwrote: 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
Re: Telling whether startup is really complete
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 bcanh...@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 ch0...@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é j...@nanthrax.netwrote: 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
Re: Telling whether startup is really complete
what do you mean? Kind regards, Andreas On Thu, Aug 9, 2012 at 6:45 PM, Johan Edstrom seij...@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 bcanh...@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 ch0...@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é j...@nanthrax.netwrote: 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
Re: Telling whether startup is really complete
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
nicely summed up; +1 :-) Kind regards, Andreas On Thu, Aug 9, 2012 at 7:40 PM, Ioannis Canellos ioca...@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
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
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
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 bcanh...@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 ch0...@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é j...@nanthrax.netwrote: 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
Re: Telling whether startup is really complete
Hi Christoph, FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a progress bar while Karaf is starting and the shell console arrives only when the startup is complete. I invite you to take a look on that. Regards JB On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote: Hi, I had another meeting with a customer today who asked me: How can I tell whether it is started up completely?. (It being our karaf-based product) So I had a look at several alternatives how I could accomplish this and had an idea I wanted to discuss. I know that I can modify the Start-level of the Shell-bundle but I don't think that's enough. Recently Christian Schneider implemented something to delay the startup of the shell until all bundles are active. I think that's a good start, but does not solve the problem completely for me. I encountered several issues with the approach: 1. There is a short delay between the point where all karaf-base-bundles are loaded and the feature-installer starts installing features specified in featuresBoot. When starting up the first time, this almost always happens ... [ 45] [Active] [5] OPS4J Base - Lang (1.3.0) [ 46] [ Resolved] [ 20] Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0), Hosts: 26 [ 47] [Active] [ 30] Apache Karaf :: System :: Shell Commands (3.0.0.SNAPSHOT) [ 48] [Active] [ 24] Apache Karaf :: Deployer :: Spring (3.0.0.SNAPSHOT) karaf@root() After a few seconds the installing of the features commences: ... [ 47] [Active] [ 30] Apache Karaf :: System :: Shell Commands (3.0.0.SNAPSHOT) [ 48] [Active] [ 24] Apache Karaf :: Deployer :: Spring (3.0.0.SNAPSHOT) [ 49] [ Installed] [ 30] Apache Karaf :: ConfigAdmin :: Core (3.0.0.SNAPSHOT) [ 50] [ Installed] [ 30] Apache Karaf :: ConfigAdmin :: Commands (3.0.0.SNAPSHOT) ... So the condition all non-fragment bundles are ACTIVE does not necessarily mean startup is complete. 2. Even if all features are installed completely and all bundles are ACTIVE, they may contain a blueprint-file and the blueprint-container might take even longer to start up. So I had an idea, I wanted to discuss: How about introducing an additional interface (like StartupIndicator with a method boolean isStartupComplete() or int getStartupProgress()). The FeatureService could implement this interface and provide the Service be registered with this additional interface. The Shell-bundle could then pick up all StartupIndicator-services and require all of them to return true before actually showing the prompt. Another StartupIndicator could check for BlueprintContainers to be available. This way, the shell would not actually have a direct dependency to the FeatureService, but could delay the prompt until all features are installed and active. Another advantage is, that users would be able to implement their own StartupIndicator-services to introduce even more delays. WDYT? kind regards, christoph -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Telling whether startup is really complete
Hey guys, While the 2.3.x code looks ways more stable than the one on the master I'm not convinced that it will solve Christoph's problem. As Christoph pointed out: There is a short delay between the point where all karaf-base-bundles are loaded and the feature-installer starts installing features specified in featuresBoot. When starting up the first time, this almost always happens I would say the relevant parts in Karaf 2.3.x are: a) StartupListener.java b) DelayedStarted.java So, If I'm correct (a) is printing the number of active bundles/available bundles till (b) set a constant which will occur the moment a bundle is added with a start lvl higher than org.osgi.framework.startlevel.beginning. That's basically fine, but this will still not fix the problem with the feature service adding bundles (with even higher start lvls) AFTER the framework startup. In addition we've the old problem of various parts (blueprint, webapps, deployer, ...) starting up async. While most of those components know when they're finished (a) cannot know. This has the advantage that it has no problem if a bundle is e.g. caught in a startup loop, but on the other hand you wont know when all bundles are active. In addition it will show the framework ready although bundles with a startup lvl higher than org.osgi.framework.startlevel.beginning are still starting. Therefore I'm curious if the process shouldn't be something like a) wait till all bundles are active or one have failed b) once all bundles are active query for a StartupIndicator service and wait till all of them either return finished or failed c) once all startup indicators are finished wait again till all (possibly new bundles) are active d) now there are maybe new StartupIndicators available or everything is up and running Do I miss anything? WDYT? Kind regards, Andreas On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Christoph, FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a progress bar while Karaf is starting and the shell console arrives only when the startup is complete. I invite you to take a look on that. Regards JB On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote: Hi, I had another meeting with a customer today who asked me: How can I tell whether it is started up completely?. (It being our karaf-based product) So I had a look at several alternatives how I could accomplish this and had an idea I wanted to discuss. I know that I can modify the Start-level of the Shell-bundle but I don't think that's enough. Recently Christian Schneider implemented something to delay the startup of the shell until all bundles are active. I think that's a good start, but does not solve the problem completely for me. I encountered several issues with the approach: 1. There is a short delay between the point where all karaf-base-bundles are loaded and the feature-installer starts installing features specified in featuresBoot. When starting up the first time, this almost always happens ... [ 45] [Active] [5] OPS4J Base - Lang (1.3.0) [ 46] [ Resolved] [ 20] Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0), Hosts: 26 [ 47] [Active] [ 30] Apache Karaf :: System :: Shell Commands (3.0.0.SNAPSHOT) [ 48] [Active] [ 24] Apache Karaf :: Deployer :: Spring (3.0.0.SNAPSHOT) karaf@root() After a few seconds the installing of the features commences: ... [ 47] [Active] [ 30] Apache Karaf :: System :: Shell Commands (3.0.0.SNAPSHOT) [ 48] [Active] [ 24] Apache Karaf :: Deployer :: Spring (3.0.0.SNAPSHOT) [ 49] [ Installed] [ 30] Apache Karaf :: ConfigAdmin :: Core (3.0.0.SNAPSHOT) [ 50] [ Installed] [ 30] Apache Karaf :: ConfigAdmin :: Commands (3.0.0.SNAPSHOT) ... So the condition all non-fragment bundles are ACTIVE does not necessarily mean startup is complete. 2. Even if all features are installed completely and all bundles are ACTIVE, they may contain a blueprint-file and the blueprint-container might take even longer to start up. So I had an idea, I wanted to discuss: How about introducing an additional interface (like StartupIndicator with a method boolean isStartupComplete() or int getStartupProgress()). The FeatureService could implement this interface and provide the Service be registered with this additional interface. The Shell-bundle could then pick up all StartupIndicator-services and require all of them to return true before actually showing the prompt. Another StartupIndicator could check for BlueprintContainers to be available. This way, the shell would not actually have a direct dependency to the FeatureService, but could delay the prompt until all features are installed and active. Another advantage is, that users would be able to implement their own StartupIndicator-services to introduce
Re: Telling whether startup is really complete
Hi Andreas, it depends what we consider when saying bundle started. From a OSGi perspective, the bundle is started. However I'm agree about the featuresBoot (AFAIR we have a Jira about that). I will take time deeper later (time to go dinner for me here ;)). Regards JB On 08/09/2012 05:08 AM, Andreas Pieber wrote: Hey guys, While the 2.3.x code looks ways more stable than the one on the master I'm not convinced that it will solve Christoph's problem. As Christoph pointed out: There is a short delay between the point where all karaf-base-bundles are loaded and the feature-installer starts installing features specified in featuresBoot. When starting up the first time, this almost always happens I would say the relevant parts in Karaf 2.3.x are: a) StartupListener.java b) DelayedStarted.java So, If I'm correct (a) is printing the number of active bundles/available bundles till (b) set a constant which will occur the moment a bundle is added with a start lvl higher than org.osgi.framework.startlevel.beginning. That's basically fine, but this will still not fix the problem with the feature service adding bundles (with even higher start lvls) AFTER the framework startup. In addition we've the old problem of various parts (blueprint, webapps, deployer, ...) starting up async. While most of those components know when they're finished (a) cannot know. This has the advantage that it has no problem if a bundle is e.g. caught in a startup loop, but on the other hand you wont know when all bundles are active. In addition it will show the framework ready although bundles with a startup lvl higher than org.osgi.framework.startlevel.beginning are still starting. Therefore I'm curious if the process shouldn't be something like a) wait till all bundles are active or one have failed b) once all bundles are active query for a StartupIndicator service and wait till all of them either return finished or failed c) once all startup indicators are finished wait again till all (possibly new bundles) are active d) now there are maybe new StartupIndicators available or everything is up and running Do I miss anything? WDYT? Kind regards, Andreas On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Christoph, FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a progress bar while Karaf is starting and the shell console arrives only when the startup is complete. I invite you to take a look on that. Regards JB On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote: Hi, I had another meeting with a customer today who asked me: How can I tell whether it is started up completely?. (It being our karaf-based product) So I had a look at several alternatives how I could accomplish this and had an idea I wanted to discuss. I know that I can modify the Start-level of the Shell-bundle but I don't think that's enough. Recently Christian Schneider implemented something to delay the startup of the shell until all bundles are active. I think that's a good start, but does not solve the problem completely for me. I encountered several issues with the approach: 1. There is a short delay between the point where all karaf-base-bundles are loaded and the feature-installer starts installing features specified in featuresBoot. When starting up the first time, this almost always happens ... [ 45] [Active] [5] OPS4J Base - Lang (1.3.0) [ 46] [ Resolved] [ 20] Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0), Hosts: 26 [ 47] [Active] [ 30] Apache Karaf :: System :: Shell Commands (3.0.0.SNAPSHOT) [ 48] [Active] [ 24] Apache Karaf :: Deployer :: Spring (3.0.0.SNAPSHOT) karaf@root() After a few seconds the installing of the features commences: ... [ 47] [Active] [ 30] Apache Karaf :: System :: Shell Commands (3.0.0.SNAPSHOT) [ 48] [Active] [ 24] Apache Karaf :: Deployer :: Spring (3.0.0.SNAPSHOT) [ 49] [ Installed] [ 30] Apache Karaf :: ConfigAdmin :: Core (3.0.0.SNAPSHOT) [ 50] [ Installed] [ 30] Apache Karaf :: ConfigAdmin :: Commands (3.0.0.SNAPSHOT) ... So the condition all non-fragment bundles are ACTIVE does not necessarily mean startup is complete. 2. Even if all features are installed completely and all bundles are ACTIVE, they may contain a blueprint-file and the blueprint-container might take even longer to start up. So I had an idea, I wanted to discuss: How about introducing an additional interface (like StartupIndicator with a method boolean isStartupComplete() or int getStartupProgress()). The FeatureService could implement this interface and provide the Service be registered with this additional interface. The Shell-bundle could then pick up all StartupIndicator-services and require all of them to return true before actually showing the prompt. Another StartupIndicator could check for BlueprintContainers to be available.
Re: Telling whether startup is really complete
Hey JB, On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré j...@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é j...@nanthrax.net wrote: Hi Christoph, FYI, we made some enhancement in karaf-2.3.x and trunk. Now you have a progress bar while Karaf is starting and the shell console arrives only when the startup is complete. I invite you to take a look on that. Regards JB On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote: Hi, I had another meeting with a customer today who asked me: How can I tell whether it is started up completely?. (It being our karaf-based product) So I had a look at several alternatives how I could accomplish this and had an idea I wanted to discuss. I know that I can modify the Start-level of the Shell-bundle but I don't think that's enough. Recently Christian Schneider implemented something to delay the startup of the shell until all bundles are active. I think that's a good start, but does not solve the problem completely for me. I encountered several issues with the approach: 1. There is a short delay between the point where all karaf-base-bundles are loaded and the feature-installer starts installing features specified in featuresBoot. When starting up the first time, this almost always happens ... [ 45] [Active] [5] OPS4J Base - Lang (1.3.0) [ 46] [ Resolved] [ 20] Apache Aries Blueprint Core Compatiblity Fragment Bundle (1.0.0), Hosts: 26 [ 47] [Active] [ 30] Apache Karaf :: System :: Shell Commands (3.0.0.SNAPSHOT) [ 48] [Active] [ 24] Apache Karaf :: Deployer :: Spring (3.0.0.SNAPSHOT) karaf@root() After a few seconds the installing of the features commences: ... [ 47] [Active] [ 30] Apache Karaf :: System :: Shell Commands (3.0.0.SNAPSHOT)
