), 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.
