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
