DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Coding
  3. Java
  4. Some Java and OSGi Errors while Working with Hive

Some Java and OSGi Errors while Working with Hive

Buddhika  Chamith user avatar by
Buddhika Chamith
·
Jul. 02, 12 · Interview
Like (0)
Save
Tweet
Share
5.72K Views

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.

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

Java (programming language)

Published at DZone with permission of Buddhika Chamith, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Stress Testing Tutorial: Comprehensive Guide With Best Practices
  • Microservices 101: Transactional Outbox and Inbox
  • Fixing Bottlenecks in Your Microservices App Flows
  • Shift-Left: A Developer's Pipe(line) Dream?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: