Analyzing Equinox Bundle Dependencies with Memory Analyzer
Join the DZone community and get the full member experience.Join For Free
Eclipse has a Plug-in Registry view, which shows the state of all plug-ins in the running instance of Eclipse. But what if you need to analyze a crashed application to see what was deployed on it? Or, like in my case, need to understand a certain bundle dependency in RCP-application that has no Plug-in Registry view?
There was nothing specified in the manifest, but yet the bundle was able to load the necessary class. Later I found out that there was a bundle fragment that injected the dependency. Analysis of the heap dump didn’t help much as there wasn’t an easy query to visualize the bundles. But it did disclose the possibility to re-create the state of an OSGi framework from the heap dump. Some investigation and voilá:
Equinox Bundle Explorer may be open via Query Browser –> Eclipse –> Equinox Bundle Explorer
During the query execution the state of the OSGi framework is read from the heap dump. The query checks a bundle registry, a service registry and an extension registry and puts all the findings together in one resulting view:
One starts with bundles and then drills down into the bundle dependencies, extensions and services. The state of the bundle (active, resolved, starting, stopping, installed, uninstalled) is immediately visible to the right of the bundle name.
Depending on the bundle, it might have:
- dependencies and dependents
- services contributed and consumed
- extension points and extensions
- hosted bundle fragments (A bundle fragment is an “incomplete” bundle. In order to function it needs to be attached to the bundle host. When attached, the fragment injects resources to the host bundle. These resources are loaded by the host class loader.)
A plug-in is an OSGi bundle. On top of OSGi standard it can register extension points and be extended with new functionality by other plug-ins. In Extension Points folder you can see which extension points a plug-in defines and which bundles declare extensions for it:
Each extension point has a name and an XML schema, which specifies the structure of the meta-data that extensions must comply. Extension contains information on the attributes and values, defined in the XML schema of the extension point:
An OSGi service is a Java object, registered into a framework with a set of properties and published under the name of a Java interface:
A bundle might register several instances of one service, but those instances should have different properties.
You can browse Bundle Explorer by services (via the toolbar menu action). Each service lists its properties, a bundle, that has registered it, and bundles using it:
Browse by extension points:
Using a context menu on a bundle, service, extension point, etc. you can jump directly to the implementation object, we’ve read the information from.
Re-creation of the state of OSGi framework from the heap dump is dependent on internal implementation classes. And because they are internal, they can change without giving a notice. If you observe abnormalities, please let me know. One thing I’ve already noticed is that information about the extension points and corresponding extensions could not be retrieved from the heap dumps, acquired in debug mode.
Equinox Bundle Explorer is in beta state. Your feedback, suggestions for improvements and feature requests are welcome!
Opinions expressed by DZone contributors are their own.