Some Java and OSGi Errors while Working with Hive
Join the DZone community and get the full member experience.Join For Free
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 .
Published at DZone with permission of Buddhika Chamith, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.