I admit it: “Using OSGi for the first time isn’t as fun as any of the hip new scripting languages.” Actually, it can be quite painful – especially in the beginning. You’re forced to think about things you actually don’t want to – or better put – you thought you don’t want to. The good news is that there is tooling support (like: BND, maven-bundle-plugin or Eclipse PDE) that can help you getting around most of the time. Unfortunately, there is still the remaining bit, that keeps nagging your brain with the “what could possible have gone wrong”. The one thing that bothered me most about it is that in many cases the steps you need to figure out what’s wrong are the same. It is simple, repetitive work you have to do, mostly only using basic OSGi know how. Also surprisingly simple, there is no tool at hand that can help you going through the necessary steps – well, till now. Lately I was so annoyed by the situation, that I started my own little open source project, aiming to fight this exact problem. Getting you up to speed and solving the simple problems you usually have when working with OSGi – especially when you start using OSGi, was my goal to achieve.
So, I am happy to introduce the (OSGi)…
Before going on explaining what it is about, what it can do and why you might wonna take a look at it, be warned! As of now, it is still a proof of concept project. It sure does offer help and is better than nothing, but I am not satisfied with some details of the API and implementation, so expect severe changes within the next couple of weeks (if not months). You’ve been warned
Anyway, the goal behind the inspector is to offer a simple framework to detect common coding mistakes in OSGi. Very simple things manifesting in ClassNotFoundExceptions, missing services, unresolved bundles or not attached fragments. It certainly is not the “one to rule them all” solution, but it is a (hopefully) decent effort to help you move faster with your OSGi development.
So, what is the inspector really. Currently, the inspector consists of three major parts: the core, the reasoner and the web GUI. The core offers basic functionality to analyze the running OSGi environment in a convenient way. This includes, but is not limited to:
- imported, exported packages with their versions, properties and directives
- provided services
- pending, removed and failed service requests (partially depending on a R4.2 runtime)
- framework events with special treatment of errors
- dynamic imports
- framework capabilities
- class look-up within the runtime (which bundles provide a specific class?)
This all is realized in one single bundle you have to deploy and start as the first bundle in your OSGi runtime (any runtime is fine, as long it is a R4.x one from any implementer).
The reasoner is the second bundle and provides the logic to solve your common problems it uses the core bundle for getting the required information to make reasonable guesses on what’s wrong and even more important, on how to fix it quickly. This part is the most experimental one. The idea is to have an extendable API that is not limited to standard OSGi problems but can be extended to solve your domain specific problems as well. The current implementation only includes one use case yet – ClassNotFoundExceptions propagated to the OSGi runtime. Other reasoners are already work in progress like failing service requests, missing services and not resolved bundles in general (bundles and fragments actually). If you can think of other common OSGi problems, please let me know!
The web gui is a convenient way to take a look at the discovered problems and the suggested solutions. It is very simple and straight forward in order to solve the problems at hand. You don’t need to use it, you could also create a simple command line tool doing exactly the same. I actually would have preferred a command line tool over a web gui, but because of the lack of a common API to provide command line extensions over OSGi implementation, I decided to not yet provide something right now. Maybe later if the the feedback suggests otherwise.
To get you started in no time, I also provide an assembly based on pax-runner that starts all bundles required correctly and allows for easy provisioning of your own domain specific bundles. There is even a very simple tutorial available at github.
So, if you’re interested, take a look at it, give it a spin and let me know what you’re thinking! Any feedback is greatly appreciated!
Here the links for further details:
Binary download: http://github.com/mirkojahn/OSGi-Inspector/downloads
Source Code: http://github.com/mirkojahn/OSGi-Inspector
Bug tracking: http://github.com/mirkojahn/OSGi-Inspector/issues
I also have plans for additional features for the next version (maybe this summer) of the inspector, like making the Web GUI extendable, including more JVM information and debugging capabilities like heap dumps or per bundle memory usage, statistics about the application like running threads, used frameworks and their versions, runtime bundle dependencies, search over many of the aforementioned features and much more, but this will be mainly based on user feedback. So stay tuned and let me know what you’re missing.
Finally here are some screen shot to give you an idea how the proof of concept looks right now
As a final note, one may ask if OSGi experts are becoming obsolete by tool support like this. I don’t think so! In my opinion, this is something that is crucial for a wider OSGi adoption and an important helper to silence the OSGi opponents by solving 90% of the beginner problems with regard to basic programming errors. It can serve as a teaching tool to tell people what not to do or how to do things better. OSGi experts now can focus on the important stuff like how to design and build truly modular applications – as they should have been for a while.