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