Some Java and OSGi Errors while Working with Hive
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.
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  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.
This error also cropped up under a similar circumstance where two packages were /> present in the system. As  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  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 , 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 .
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 .
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)