Learn by Errors : Java + OSGi

Recently I worked on getting Apache Hive work inside an OSGi environment. While not proving to be a proverbial piece of cake (software right?.. Why am I not surprised? :) ), it led me through an assortment of Java and OSGi errors. Here I am listing some of them that bit me bit hard (no pun intended) so that I thought of making a blog out them just for my own satisfaction.

java.lang.VerifyError

I got this nastiness during initialization of one of OSGi service components. The culprit was not immediately identifiable since the offending bundle was in ACTIVE state. On the surface everything looked fine except for the fact the Hive server which was supposed to start during the initialization of the service component present in the bundle was not up and running. A quick ‘ls’ in the OSGi console revealed the service component is in ‘unsatisfied’ state. Finally a ‘comp’ revealed the root cause, the VerifyError.

The VerifyError can occur if the runtime dependency of a class is different to that of the dependency that was used at compilation time. For example if the method signatures have changed between the dependencies then this error would result. This is nicely explained at [1] in the accepted answer. As it turned out slightly different versions of a package had been exposed in two bundles causing the Hive bundle to pick up a different version over the version that was in the compilation environment. Proper OSGi versioning turned out to be the solution.

java.lang.IncompatibleClassChangeError

This error also cropped up under a similar circumstance where two packages were present in the system. As [2] clearly explains, the reason for this in my case was an interface being changed to an abstract class between the conflicting package versions. Again the versioning helped to save the day.

java.lang.LinkageError : loader constraint violation in xxxx – blah …

Now this seems to be a famous error specially in OSGi enviornments. Main root cause seems to be two classes loaded by different ClassLoaders coming in to contact in a certain way. For example say Class A object accept a Class B object as a method parameter. Class B is loaded by ClassLoader-A which also loads Class A. But at the method invocation time how ever an object of Class B which has been loaded by ClassLoader-B is passed as an argument to an object of Class A which has been loaded by ClassLoader-A. Now the result would be a big fat LinkageError with a very verbose error message.

The graph based class loadingstructure in OSGi makes it specially conducive to these kind of errors. In my case the culprit was a package which had been duplicated in two different bundles and a particular class in that package loaded by the separate ClassLoaders of each of the bundles coming in to contact via a third bundle present in the system during a method call. So this was a case of not following “import what you export” best practice [3] in OSGi. Doing so would help to reduce the exposure of duplicated packages across bundles and help to maintain a consistent class space for a given package. And so this turned out to be the resolution for that in this case.

Package uses conflict: Import-Package: yyy; version=”x.x.x”

I had my fair share of this inconvenience thrown at my face every so often during the exercise. There are two excellent posts [4],[5] exactly on this issue at SpringSource which helped a lot. However let me summarize my learning on this issue. Simply if a bundle is being exposed to two versions of the same package through a direct import and via a uses constraint this error would come up. The diagram best illustrates this situation.

The bundle A imports org.foo version 1.0.0 directly. However it also imports bundle org.bar from bundle B. However as it turns out package org.bar also uses org.foo package albeit it’s a different version (2.0.0) than that of the version imported by bundle A. Now bundle A is directly wired to version 1.0.0 of org.foo and also being exposed to the version 2.0.0 of org.foo due to the import of org.bar which is using version 2.0.0 of org.foo. Now since a bundle cannot be wired to different versions of the same package, a uses conflict would come up with offending import org.bar as the root cause. (e.g: Package uses conflict: Import-Package: org.bar; version=”0.0.0?). The solution would be to change package import versions of org.bar in either bundle A or bundle B so that both would be pointing to the same package version. Another excellent blog by Neil Bartlett on this can be found at [6].

java.lang.UnsatisfiedLinkError

One of my friends at work came across this while trying to incorporate another third party library in to our OSGi enviornment. JavaDocs goes on to say that this gets “Thrown if the Java Virtual Machine cannot find an appropriate native-language definition of a method declared native”. The offending library was a linux .so (dynamically linked library) file which was not visible to bundle ClassLoader at runtime. We were able to get it working by directly including the library resource to the bundle ClassLoader. An earlier attempt on setting this resource on TCCL (Thread Context ClassLoader) failed and this let us to the realization that the TCCL is typically not the bundle class loader. A good reading on TCCL under Equinox OSGi enviornment can be found at [7].

[1] http://stackoverflow.com/questions/100107/reasons-of-getting-a-java-lang-verifyerror
[2] http://stackoverflow.com/questions/1980452/what-causes-java-lang-incompatibleclasschangeerror
[3] http://blog.osgi.org/2007/04/importance-of-exporting-nd-importing.html
[4] http://blog.springsource.org/2008/10/20/understanding-the-osgi-uses-directive/
[5] http://blog.springsource.org/2008/11/22/diagnosing-osgi-uses-conflicts/
[6] http://njbartlett.name/2011/02/09/uses-constraints.html
[7] http://wiki.eclipse.org/ContextClassLoader_Enhancements

Reference: Learn by Errors : Java + OSGi from our JCG partner Buddhika Chamith at the Source Open blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


4 + six =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close