Some Java and OSGi Errors while Working with Hive
Some Java and OSGi Errors while Working with Hive
Join the DZone community and get the full member experience.Join For Free
Hortonworks Sandbox for HDP and HDF is your chance to get started on learning, developing, testing and trying out new features. Each download comes preconfigured with interactive tutorials, sample data and developments from the Apache community.
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.