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