Lately, I was working on a problem, which really got me. I had a class throwing an exception for no obvious reason and the provided message wasn’t helping either. When I tried to take a look at the class, causing this problem, I noticed that I had no idea, where the class was actually coming from. Working with a lot of bundles, you usually don’t have all of them available in your development environment (especially when you work remotely on an external device f.i.), so using the search capabilities of your favorite IDE is not always an option. One might say that with well defined conventions, this is not much of a problem, but you are not always using your own code (actually most of the time I don’t) and you can’t dictate the way they create their components. Standards are great, but only if everyone complies with them. Anyway, to solve my problem, I had to import all my bundles into Eclipse and and search inside of Eclipse after the class – not really convenient.
Over the weekend, I decided to do something about this inconvenience and started to create a bundle to do this job in the running OSGi container. I just defined a service interface with a single method, a console extension for the Equinox and ProSyst mBS Console and implemented the interface in a handful lines of code and voila, here it is – the inspector bundle. Yet only providing one very simple command to show the bundles containing the given class. The service interface (net.mjahn.tools.inspector.IBundleUtils) is as simple as you can imagine. All it does is providing you the bundle having the given class in its class path (not the bundle class space – the bundle must provide the defining class loader of the class).
No magic and certainly no rocket science, but quiet handy when you don’t have all your bundles in the IDE. If someone is interested, the jar in a first version can be downloaded from the tools section here.