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 l ary 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 l ary /> was a linux .so (dynamically linked l ary) file which was not visible to /> bundle ClassLoader at runtime. We were able to get it working by directly /> including the l ary 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