blob: 175a3c90902ebabef8d858bab15b41998de26b3f [file] [log] [blame]
Carsten Ziegelerf76e64b2011-11-18 09:40:49 +00001OSGi Service Diagnostics and WebConsole Plugin
2==============================================
3
4This projects aims at easing diagnostics of OSGi services and finding about missing dependencies.
5
6Typically 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!
7
8The 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.
9
10Typically, 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.
11
12Similarly, 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.
13
14Project organization (core):
15============================
16* servicediagnostics: the API package. It holds the main service interface as well as the plugin interface, to extend to other dependency management systems
17
18* 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.
19
20* 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.
21
22The "sample" part simply contains some test classes and a helper class to launch Felix.
23
24How to build the project:
25=========================
26
27> mvn install
28
29How to run:
30===========
31I'm providing a simple run script just to try out the service.
32Unfortunately, org.json and scala-library don't come readily packaged as OSGi bundles, so we need to wrap them ourselves and copy these runtime dependencies into a "lib" directory under the project root:
33lib/json-osgi.jar
34lib/scala-library-osgi.jar
35
36These libraries can be easily created using Bnd:
37> java -jar bnd.jar wrap $HOME/.m2/repository/org/scala-lang/scala-library/2.8.1/scala-library-2.8.1.jar
38> mv scala-library-2.8.1.bar lib/scala-library-osgi.jar
39
40> java -jar bnd.jar wrap $HOME/.m2/repository/org/json/json/20090211/json-20090211.jar
41> mv json-20090211.bar lib/json-osgi.jar
42
43Once this is done, you can simply run:
44> ./run.sh
45
46It should display:
47[INFO] Started jetty 6.1.x at port(s) HTTP:8080
48
49You can then point your browser to
50http://localhost:8080/system/console/servicegraph
51
52(login/password is admin/admin)
53then click on either "Unavail" or "All".
54The "bubbles" can be dragged around for better readability. The colors are random and don't mean anything.
55On the "All" view, arrows point from bundles to the services they use.
56On the "Unavail" view, arrows point from a leaf component to its missing dependencies.
57
58(note: the lib directory is provided for dependencies that are not readily available as OSGi bundles from maven)
59
60Issues & TODOs:
61===============
62* use of JSONObject in Servlet.scala is a bit awkward, but Scala's native json is still incomplete..
63* no support for service properties; needs to be added.
64* no support for iPojo, Blueprint, basic ServiceTrackers... more plugins could be developed. I only wrote the ones i'm using.