Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Fri, 18 Nov 2011 09:42:51 +0000 (UTC)
From: "Carsten Ziegeler (Resolved) (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: 
 <1631187858.42745.1321609371830.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1653766423.3566.1316724146101.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (FELIX-3128) A Service Diagnostics service and
 graphical WebConsole plugin
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/FELIX-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler resolved FELIX-3128.
-------------------------------------

    Resolution: Fixed

Imported the code in revision 1203551
                
> 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
>            Assignee: Carsten Ziegeler
>            Priority: Minor
>         Attachments: org.apache.felix.servicediagnostics.tgz, 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira