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.net>wrote:
>>
>>> Hi,
>>>
>>> I'm not fully agree.
>>>
>>> Karaf is a container, with the purpose to be fast, lightweight.
>>> So what does it mean "Karaf started" ?
>>>
>>> For instance, I gonna compare with JEE application server. When do you
>>> consider that an application server is started:
>>> - when the application server itself is up and running ?
>>> - when the resources in the application server are up (datasource, JMS
>>> server, etc) ?
>>> - when the applications are started ?
>>>
>>> All is question of perspective.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/09/2012 05:06 PM, Christoph Gritschenberger wrote:
>>>
>>>> I understand that when using karaf as a developer one would want the
>>>> shell as fast as possible and don't wait for a minute or something.
>>>> That's why Christian implemented the "Press Enter to start it
>>>> anyway"-thing I think.
>>>> Maybe it's a better option to make it optional after all and disable it
>>>> in the karaf-distributions, but allowing users to modify some
>>>> config-file to get the delayed-console-startup.
>>>> This way developers are not annoyed by long startup-times, but
>>>> karaf-based products could provide the user with proper feedback.
>>>>
>>>> And about the uptime vs startup time: I agree with Christian here. But
>>>> we have a customer who develops his own external systems that interact
>>>> with our karaf-based application. Their developers complained, they
>>>> can't tell when karaf is started, and they need to start and stop it
>>>> more often during development, but don't really want to get into karaf
>>>> to deeply because it's just an external system.
>>>>
>>>> I could also try to implement something like that myself. The solution
>>>> with the "StartupIndicator"-services makes it easier to maintain because
>>>> I can describe the conditions to be met in the corresponding bundle
>>>> (which I reuse in several assemblies).
>>>> I could create an additional bundle querying those services and delay
>>>> the console with the right use of start-levels.
>>>>
>>>> But at some points a tighter integration into karaf would be nice (like
>>>> the FeatureService).
>>>>
>>>> kind regards,
>>>> christoph
>>>>
>>>>
>>>> On 09/08/12 13:59, Christian Schneider wrote:
>>>>
>>>>> This is almost like the current solution.
>>>>>
>>>>> The only difference is that the shell currently only starts when the
>>>>> startlevel is reached or when the user presses enter.
>>>>>
>>>>> I also thought about printing a message when karaf finished loading. The
>>>>> problem is that the user might just be typing at that moment so the
>>>>> message would scramble his input. This
>>>>> is why the current solution waits. When the user presses enter the
>>>>> progress bar is stopped and no further messages are printed. So we do
>>>>> not interfere with the user input.
>>>>>
>>>>> So I really like what we have right now and think we should not add a
>>>>> further listener to the startup. Like proposed before.
>>>>>
>>>>> The case of monitoring is completely different and I think the new
>>>>> BundleService in karaf 3 can help with that case a lot like mentioned in
>>>>> my other mail.
>>>>>
>>>>> About the startup time vs run time in production Achim mentioned. This
>>>>> is definately true for the long run. We should remember though that the
>>>>> startup of karaf is the first thing a users sees when starting karaf for
>>>>> the first time. So I think it is worth putting some effort into the
>>>>> startup to make the first experience with karaf a pleasant one for the
>>>>> user. For many people these first moments may decide if they are willing
>>>>> to put more effort into understanding and using karaf or try the next
>>>>> product.
>>>>>
>>>>> Christian
>>>>>
>>>>> Am 09.08.2012 13:19, schrieb Jamie G.:
>>>>>
>>>>>> Just my 2 cents CAD...
>>>>>>
>>>>>> I think that this effort may be leading to diminishing returns ..
>>>>>> there are many edge cases we may hit here, and i don't want to see
>>>>>> Karaf's console take minutes to become available. So here is my
>>>>>> alternative suggestion:
>>>>>>
>>>>>> Allow Karaf console to come up as per start level as we've been doing
>>>>>> for a long time now, but include two new messages that will be printed
>>>>>> to the console screen:
>>>>>>
>>>>>> 1: Welcome to Karaf ${version}, bundles are still loading....
>>>>>> 2: All bundles started, happy hacking!
>>>>>>
>>>>>> The message content can be changed to suit our needs - the main thing
>>>>>> is that the console will be available to users right away.
>>>>>>
>>>>>> Cheers,
>>>>>> Jamie
>>>>>>
>>>>>> On Thu, Aug 9, 2012 at 5:29 AM, Guillaume Nodet <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.net<javascript:;>**>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Andreas,
>>>>>>>>>
>>>>>>>>> it depends what we consider when saying "bundle started". From a OSGi
>>>>>>>>> perspective, the bundle is started.
>>>>>>>>>
>>>>>>>> I think there are various lvls here (and thats the reason why I
>>>>>>>> consider the ReadyService, as proposed by Christoph, such a good
>>>>>>>> idea). Consider that we register those ReadyServices via the activator
>>>>>>>> they will be available once the bundle is active; once all framework
>>>>>>>> bundles are active the feature service can state once he had installed
>>>>>>>> all features, the deployer can state once all bundles from the deploy
>>>>>>>> folder had been added, a custom application bundle can e.g. check if a
>>>>>>>> specific url could be reached and so on; This could finally provide a
>>>>>>>> "suite" which could be adapted to give a user a quite accurate "real"
>>>>>>>> start-point (even if it requires some manual adaption). I'm really
>>>>>>>> interested what you think about this once you've given it a little bit
>>>>>>>> more time for consideration :-)
>>>>>>>>
>>>>>>>> However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>>>>>>>>
>>>>>>>> that).
>>>>>>>>
>>>>>>>>> I will take time deeper later (time to go dinner for me here ;)).
>>>>>>>>>
>>>>>>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>>>>>>> the hell are you :-)
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>>>>>>
>>>>>>>>>> Hey guys,
>>>>>>>>>>
>>>>>>>>>> While the 2.3.x code looks ways more stable than the one on the
>>>>>>>>>> master
>>>>>>>>>> I'm not convinced that it will solve Christoph's problem. As
>>>>>>>>>> Christoph
>>>>>>>>>> pointed out:
>>>>>>>>>>
>>>>>>>>>> "There is a short delay between the point where all
>>>>>>>>>> karaf-base-bundles
>>>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>>>> almost always happens"
>>>>>>>>>>
>>>>>>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>>>>>>
>>>>>>>>>> a) StartupListener.java
>>>>>>>>>> b) DelayedStarted.java
>>>>>>>>>>
>>>>>>>>>> So, If I'm correct (a) is printing the number of active
>>>>>>>>>> bundles/available bundles till (b) set a constant which will occur
>>>>>>>>>> the
>>>>>>>>>> moment a bundle is added with a start lvl higher than
>>>>>>>>>> "org.osgi.framework.**startlevel.beginning". That's basically
>>>>>>>>>> fine, but
>>>>>>>>>> this will still not fix the problem with the feature service adding
>>>>>>>>>> bundles (with even higher start lvls) AFTER the framework startup.
>>>>>>>>>> In
>>>>>>>>>> addition we've the "old" problem of various parts (blueprint,
>>>>>>>>>> webapps,
>>>>>>>>>> deployer, ...) starting up async. While most of those components
>>>>>>>>>> know
>>>>>>>>>> when they're finished (a) cannot know. This has the advantage that
>>>>>>>>>> it
>>>>>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>>>>>>> the other hand you wont know when all bundles are active. In
>>>>>>>>>> addition
>>>>>>>>>> it will show the framework ready although bundles with a startup lvl
>>>>>>>>>> higher than "org.osgi.framework.**startlevel.beginning" are still
>>>>>>>>>> starting.
>>>>>>>>>>
>>>>>>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>>>>>>
>>>>>>>>>> a) wait till all bundles are active or one have failed
>>>>>>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>>>>>>> and wait till all of them either return finished or failed
>>>>>>>>>> c) once all startup indicators are finished wait again till all
>>>>>>>>>> (possibly new bundles) are active
>>>>>>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>>>>>>> is up and running
>>>>>>>>>>
>>>>>>>>>> Do I miss anything? WDYT?
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Andreas
>>>>>>>>>>
>>>>>>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré
>>>>>>>>>> <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] [
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> FuseSource, Integration everywhere
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> Charles Moulliard
>> Apache Committer / Sr. Pr. Consultant at FuseSource.com
>> Twitter : @cmoulliard
>> Blog : http://cmoulliard.blogspot.com
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> OPS4J Pax for Vaadin
> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
> Lead
> blog <http://notizblog.nierbeck.de/>
