+2 pence.
On Aug 9, 2012, at 5:26 AM, Achim Nierbeck wrote:
> Hi,
>
> I have to second Jamie on this, cause right now I'm quite happy with
> having a shell right away so
> if I'm really in need for knowing if all bundles are up and runnig
> I'll do a "la" and I'm fine knowing how it's proceeding.
> For me there is no real need to hide the shell from users, cause let's
> take a look on how long is a Server process supposed to run
> at best forever or the time the machine dies. So basically it'll have
> the same up-time as the machine which will be longer on
> linux then on windows. Compared to the uptime the time it takes to
> load the complete set of bundles (if it's about a 100) is about 3
> minutes (worst case).
> Now 3 / infinity = 0 so I don't see a point of making so much fuzz
> about a 3 minutes window for starting a fresh karaf (a reboot is
> always much faster).
> For knowing if my application is around I'm with charles to say, hey
> use JMX to monitor your application. There are plenty of Nexus
> connectors around to monitor
> any application with JMX.
>
> Just my 2 cents here ...
>
> regards, Achim
>
> 2012/8/9 Jamie G. <jamie.goody...@gmail.com>:
>> 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
>
>
>
> --
>
> 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/>
