Indicators

Working on OSGi-based applications you will often have problems caused by Package Wiring conflicts, in other words, bundles are not importing the right packages at runtime. Package Wiring conflicts cause different problems, most common are:

• Class Not Found Exceptions: You will get this exception when the packages of needed classes are not imported by your bundle.
• Class Casting Exceptions: You will get this exception when the different bundles use different versions of the same class resulted by importing different versions of the same package.
• Annotations not being processed: Some annotation on your classes/methods/fields are not being processed by classes from other bundles. This is caused by the fact that the class which has the annotation uses a different version of the annotation from the one used by the class which processes the annotation. e.g., You have a Book class which has the JAXB annotation @XmlRoot, if you have two version of the @XmlRoot annotation in the OSGi Environment and the JAXB implementation bundle consumes a different version than the one you've applied to the Book class, then @XmlRoot annotation on your class will not be visible for the JAXB processor.

Causes

Below are most common causes of Package Wiring conflicts:

• Needed packages are not being imported: I know that it seems silly writing this down, but come on, it's a common cause after all...
• Multiple Bundles Export different versions of the same package: Having multiple versions of the same package it becomes possible that different bundles import different versions of the same package.
• The application contains bundles that export common JSR API classes: Some of the common JSR API classes are already contained in the JRE or JDK which in turn are exported as System Bundle packages, this will make the environment have different versions of the same package which can cause Package Wiring conflicts. For instance, the StAX API is not contained in JRE 1.5 but is contained in JRE 1.6, so the same set of bundles might behave differently in these environments, where in JRE 1.5 it will work but in JRE 1.6 it could have Package Wiring conflicts caused by the existence of multiple versions of the same package.

Solution?

Unfortunately, there is no silver bullet kind of solution for Package Wiring conflicts, neither clear indicators that would tell you that the problem you have is caused by a Package Wiring conflict, so basically you will need to investigate the problem yourself. The purpose of this article is to present strongest indicators of Package Wiring conflicts and possible causes for them.

Felix Web Console comes in handy when investigating Package Wiring conflicts since it shows you the packages that each bundle actually imports at runtime and the name of the bundles that export the imported packages. For instance, when I have a Class Cast Exception (indicator) I conclude that I have different versions of the same package imported by two different bundles that communicate with each other (cause), at times like this, I use Felix Web Console to check which version of the package each of my bundles import (cause verification). On how to launch Felix Web Console from your application within 2 minutes can be found here and an example OSGi-based application which runs the Admin Console can be downloaded from here.

[Felix Web Console Screenshot: The point of interest here is the marked "javax.xml.stream" package, since I have it exported from two bundles, so I used the console to check which version it was wired to]