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