what do you mean? Kind regards, Andreas
On Thu, Aug 9, 2012 at 6:45 PM, Johan Edstrom <[email protected]> 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 <[email protected]> >> 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 <[email protected]>: >>>> Well said JB. This is exactly what I have explained this morning. >>>> >>>> On Thu, Aug 9, 2012 at 5:24 PM, Jean-Baptiste Onofré >>>> <[email protected]>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 <[email protected]> >>>>>>>> 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é >>>>>>>>>> <[email protected]<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é >>>>>>>>>>>> <[email protected]> >>>>>>>>>>>> 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é >>>>> [email protected] >>>>> 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/> >
