Sorry for the direct email, we should probably stick to the mailing list to avoid forking discussions (see chris's mail below).
I agree with Richard that extenders can have many different purposes, not only DI, and indeed extenders do not prevent a bundle from starting; at most they won't be able to do what they're supposed to do (but other extenders could work on the same bundle) First extenders typically track bundles only once they're started (or installed, in which case they don't care about the bundle life cycle). Extenders typically track a resource in the bundle or a manifest header or scan annotations.. One common error is to misspell the manifest header or file name (when they're not automatically generated). This situation is pretty hard to diagnose since the extender won't even start to do anything with the bundle. Then if really it comes down to an uncaught exception when starting a service (or when parsing some extender specific resource), the extender implementation could choose to simply stop the bundle but that would probably be a pretty harsh behavior! The bundle status directly reflects the bundle life cycle: installed, started, stopped.. fairly simple. But a "status" which would reflect an aggregation of the status of all possible extenders seem quite hard to represent, and interpret. The extender implementation can simply dump the exception in the logs and possibly reflect the error in a dedicated webconsole plugin. Alternatively, a standardized way of looking at it could be that all extenders register an "Error" object containing the extender ID, the bundle that failed and an error description. Then a centralized service (or webconsole plugin) could display all such errors. Arjun On Fri, Oct 11, 2013 at 3:39 PM, Christian Schneider < [email protected]> wrote: > Thanks for sharing this infos. I heard about the project some time ago > but never tested it. I think this project could > also profit from a standardization as then perhaps the plugins you > describe could be already provided by the frameworks. > > I think we are talking about two different types of diagnostics. My > primary concern was to report if a bundle could not be initialized because > of static errors in the DI config. So this is on the bundle level. > > Of course there is also a second level of diagnostics. If there are no > static errors the DI framework will try to initialize the components. Then > we are of course interested about the status and dependencies of each > component individually. > > So I think ideally diagnostics should provide both levels. > > On top of these low level diagnostics we then could also need a high level > view with a graphical representation and root cause analysis. This could > also be described but I think it should be a level above the basic > diagnostic informations. > > Christian > > > > > On 11.10.2013 14:49, Arjun Panday wrote: > > Hi, > > I just noticed this thread and I meant to draw your attention to a Felix > subproject I started couple of years ago to address precisely this question > of service diagnostics using various DI frameworks. > > The idea is to merge and diagnose service dependencies across DI > frameworks and point directly to the root(s) missing service(s), which can > quickly become complicated for a growing number of services. For instance: > > If A using SCR depends on B provided by DependencyManager > and B depends on C provided by SCR > and C depends on a missing service D > > The plugin will display a graph only showing the missing C to D > dependency; all intermediates (A and B) are hidden because they will > automatically be resolved if D becomes available. > The plugin also attempts to detect potential loops in service > dependencies. > > While the primary use case is a graphical representation in the > webconsole, the code is organized to be extended and reused: > - the diagnostics engine is itself a service which can be used to > programmatically diagnose service issues for other uses (logging, > alarms...) > - DI frameworks specifics are plugins implementing a simple interface: for > now only Felix SCR and Felix DependencyManager plugins are implemented, but > additional plugins for Blueprint implementations, iPojo or others could be > easily added, even as separate bundles. > > As it was mentioned in the thread, diagnostics care only about services > and not bundles, as one bundle may provide many services, even using > several DI frameworks. > > Incidentally, the plugin also presents other graphs of service to > bundles dependencies or ownership as well as a view of the service > registry, but these only show registered (and thus resolved) services and > can quickly become difficult to read with numerous services. > > The project is called Web Console ServiceDiagnostics Plugin and can be > found on Felix' download page: > > http://apache.websitebeheerjd.nl//felix/org.apache.felix.servicediagnostics.plugin-0.1.3.jar > > It has a dependency on the following bundles (basically scala, the > webconsole and the DI frameworks used, so you're probably just missing > scala in the list): > scala-library-2.10.0.jar > org.apache.felix.http.jetty-2.2.0.jar > org.apache.felix.webconsole-4.2.0.jar > com.springsource.org.apache.commons.fileupload-1.2.1.jar > com.springsource.org.apache.commons.io-1.4.0.jar > json-20090211_1.jar > org.apache.felix.dependencymanager-3.0.0.jar > org.apache.felix.dependencymanager.shell-3.0.0.jar > org.apache.felix.scr-1.6.0.jar > org.osgi.compendium-4.2.0.jar > org.apache.felix.shell-1.4.3.jar > org.apache.felix.webconsole.plugins.shell-1.0.0-SNAPSHOT.jar > > The source code (in Scala) is fairly small and can be viewed here: > > http://svn.apache.org/repos/asf/felix/trunk/webconsole-plugins/servicediagnostics/core/ > > I hope this looks like what you may be looking for. It certainly proved > useful in my organization to track service related issues and ease the work > of developers. > > Best regards, > Arjun Panday > > > > -- > Christian Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
