You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Arjun Panday (JIRA)" <ji...@apache.org> on 2011/09/22 22:49:27 UTC
[jira] [Updated] (FELIX-3128) A Service Diagnostics service and
graphical WebConsole plugin
[ https://issues.apache.org/jira/browse/FELIX-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arjun Panday updated FELIX-3128:
--------------------------------
Attachment: servicediagnostics.tar.gz
md5sum servicediagnostics.tar.gz :
8a5cd6b9f86b2d7676cb36bc85760342
> A Service Diagnostics service and graphical WebConsole plugin
> -------------------------------------------------------------
>
> Key: FELIX-3128
> URL: https://issues.apache.org/jira/browse/FELIX-3128
> Project: Felix
> Issue Type: New Feature
> Components: Web Console
> Reporter: Arjun Panday
> Priority: Minor
> Attachments: servicediagnostics.tar.gz
>
>
> Hi all,
> I'd like to suggest/contribute the attached project.
> The project aims at easing diagnostics of OSGi services and finding about missing dependencies.
> Typically in a large system with many cascading dependencies managed by different trackers such as DeclarativeService, DependencyManager or others, tracking the root cause of a top level service not being started can become very cumbersome. When building service oriented architectures, it is often the case that a single missing requirement will lock a full stack of services, but to find that one requirement is like finding a needle in a haystack!
> The basic idea here is to ask each dependency manager instance about its unresolved dependencies, merge all answers and filter the result to keep only the root causes.
> Typically, if A depends on B which depends on C which depends on D, and D is nowhere to be found, I need only show the "C -> D" missing requirement; if D is resolved, then the whole stack is unlocked.
> Similarly, if D is known by another dependency management system, but unregistered because it depends on E which is missing, then only the "D -> E" requirement is relevant.
> The proposed code is composed as follows:
> * servicediagnostics: the API package. It holds the main service interface as well as the plugin interface, to extend to other dependency management systems
> * servicediagnostics.impl: the implementation package. It contains plugins implementations for org.apache.felix.scr and org.apache.felix.dependencymanager, as well as the main service implementation.
> * servicediagnostics.webconsole: a Felix WebConsole plugin that displays a graphical view of the diagnostics result. Alternatively it can also show a graph of all services currently registered in the service registry and the bundles using them. See Screenshot-notavail.png and Screenshot-all.png. Using the Raphael graffle library (http://raphaeljs.com/graffle.html) allows for nice interactive views of the service registry.
> The attached package is provided as a maven project, along with a sample runner. Simply untar the files, run mvn install and then run.sh.
> Follow the Readme file for details.
> It is not perfect and still needs some improvements (in handling service filters for instance) but as such it is already quite useful.
> I hope you'll like the idea.
> Regards,
> Arjun
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira