Hi Jan, It is an interesting approach. Determining whether or not the framework > is in a useable state is a rather difficult problem for dynamic > systems. The problem obviously being that when a bundle appears to be > active, it does not necessarily imply that its services are ready for > duty. > That's absolutely right. On top of that, its services being up might not mean your application is ready. You might have some Components that need to do some costly system initialisation before your whole system is considered "ready", including the top level of your application.
> > In the past, I've worked with another, somewhat similar, utility (see > [1]) that provides a callback whenever the framework reached a "stable" > state (or becomes "unstable") so I could act upon that. That's great! We were thinking of whether we want a callback approach, but that can be implemented as a consumer for our monitor. > What I liked > about this was that it did not require me to implement "readiness > checks" for any of my services (though I see that it might be useful to > provide such custom checks occassionally). > What we provide ootb is: * Check for the framework being up, with details (more meat to it could come later). i.e. all bundles, including the system bundle are active. * Two check for a configurable list of services and components that one consideres necessary for the application to be ready. * The root cause analysis for the checks above (why are they not up?) Regarding implementing custom checks, our view is that (especially for an enterprise product), there is a separation of roles between people owning a packaged delivery (the application as it comes out of engineering, whatever form that takes) and the people owning different deployments. One can have multiple (types of) deployments, with different configuration. Having the ability to develop and install custom readiness checks at different layers with minimal effort, while still having a unified interface for getting the readiness status and reuse deployment automation tooling, is quite valuable. Sorry for the convoluted message :) tl; dr: some applications might need other things that are not a service being up to be ready + unified interface for aggregated status and being able to contribute "my own checks". > That said, I think it would be interesting to have an addon for Felix > that has minimal dependencies and combines both approaches :) > Interesting. I'm not very familiar with the terminology. What do you mean by addon exactly? Could you provide more details about that? BTW, thanks everyone for the involvement and support. I'm really excited about this! - Andrei > 1. https://github.com/beinformed/osgitest/tree/master/com.beinformed.fr > amework.osgi.frameworkstate > > Regards, > > Jan Willem > >
