Thanks Carsten, excellent news!
I've sent the forms to the secretary and legal service; awaiting for
their acknowledgement.
Best regards,
Arjun
On 10/04/2011 09:07 AM, Carsten Ziegeler (Commented) (JIRA) wrote:
[
https://issues.apache.org/jira/browse/FELIX-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119928#comment-13119928
]
Carsten Ziegeler commented on FELIX-3128:
-----------------------------------------
Arjun, the vote to accept your contribution has passed:
http://www.mail-archive.com/dev@felix.apache.org/msg23154.html
If you haven't already filed an ICLA and a Software Grant yet, then do so,
since that'll be the next requirement for proceeding.
For more information see here:
As stated in
http://incubator.apache.org/ip-clearance/ip-clearance-template.html:
A software grant must be provided to the ASF. This grant can either be done by
the ASF Corporate CLA (via Schedule B) or the traditional License Agreement.
Acceptable methods of sending the grant to the ASF includes:
snail-mail to the ASF office and/or ASF officer
FAXing to the ASF office and/or an ASF officer
Emailing the scanned document to secret...@apache.org and
legal-arch...@apache.org.
Thanks.
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: 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
