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.

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/context class loader_enhancements