Hi, >From my point of view, this is not because a bundle is started or even an OSGI service is registered (in the OSGI registry) that we could say that the "Services" deployed on the platform (Bundles, Camel routes, Web Services, Web modules, ....) are operational. This is why for that reason I always recommend to our clients that they add in their services some MBeans methods, log trace, use WireTap EIP, ... to capture that information and report it into a dashboard (DataBase, ...) that operational guys can use to be informed if everything is "operational = services well deployed and started)
Regards, Charles Moulliard Apache Committer / Sr. Pr. Consultant at FuseSource.com Twitter : @cmoulliard Blog : http://cmoulliard.blogspot.com On Thu, Aug 9, 2012 at 5:55 AM, Andreas Pieber <anpie...@gmail.com> wrote: > Hey JB, > > On Thu, Aug 9, 2012 at 5:16 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > 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] [ Resolved] [ 20] Apache Aries Blueprint Core > >>>> Compatiblity > >>>> Fragment Bundle (1.0.0), Hosts: 26 > >>>> [ 47] [ Active] [ 30] Apache Karaf :: System :: Shell > >>>> Commands > >>>> (3.0.0.SNAPSHOT) > >>>> [ 48] [ Active] [ 24] Apache Karaf :: Deployer :: > Spring > >>>> (3.0.0.SNAPSHOT) > >>>> karaf@root()> > >>>> > >>>> After a few seconds the installing of the features commences: > >>>> > >>>> ... > >>>> [ 47] [ Active] [ 30] Apache Karaf :: System :: Shell > >>>> Commands > >>>> (3.0.0.SNAPSHOT) > >>>> [ 48] [ Active] [ 24] Apache Karaf :: Deployer :: > Spring > >>>> (3.0.0.SNAPSHOT) > >>>> [ 49] [ Installed] [ 30] Apache Karaf :: ConfigAdmin :: > Core > >>>> (3.0.0.SNAPSHOT) > >>>> [ 50] [ Installed] [ 30] Apache Karaf :: ConfigAdmin :: > >>>> Commands > >>>> (3.0.0.SNAPSHOT) > >>>> ... > >>>> > >>>> So the condition "all non-fragment bundles are ACTIVE" does not > >>>> necessarily mean "startup is complete". > >>>> > >>>> 2. Even if all features are installed completely and all bundles are > >>>> ACTIVE, they may contain a blueprint-file and the blueprint-container > >>>> might take even longer to start up. > >>>> > >>>> > >>>> So I had an idea, I wanted to discuss: > >>>> How about introducing an additional interface (like "StartupIndicator" > >>>> with a method "boolean isStartupComplete()" or "int > >>>> getStartupProgress()"). The FeatureService could implement this > >>>> interface and provide the Service be registered with this additional > >>>> interface. > >>>> The Shell-bundle could then pick up all "StartupIndicator"-services > and > >>>> require all of them to return true before actually showing the prompt. > >>>> Another StartupIndicator could check for BlueprintContainers to be > >>>> available. > >>>> > >>>> This way, the shell would not actually have a direct dependency to the > >>>> FeatureService, but could delay the prompt until all features are > >>>> installed and active. > >>>> > >>>> Another advantage is, that users would be able to implement their own > >>>> "StartupIndicator"-services to introduce even more delays. > >>>> > >>>> WDYT? > >>>> > >>>> kind regards, > >>>> christoph > >>>> > >>> > >>> -- > >>> Jean-Baptiste Onofré > >>> jbono...@apache.org > >>> http://blog.nanthrax.net > >>> Talend - http://www.talend.com > > > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com >
