Conundrum Solved: Odd Linkage Error in A4J

June 29th, 2010 Via Tsuji, Consultant  (email the author)

Problem: Application began spewing out the following error when clicking on our Ajax-ified radio buttons:

java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.ajax4jsf.org.w3c.tidy.DOMNodeImpl.setUserData(Ljava/lang/String;Ljava/lang/Object; Lorg/w3c/dom/UserDataHandler;)Ljava/lang/Object;"  the class loader (instance of com/ibm/ws/classloader/CompoundClassLoader) of the current class, org/ajax4jsf/org/w3c/tidy/DOMNodeImpl, and the class loader (instance of <bootloader>) for interface org/w3c/dom/Node have different Class objects for the type

Background: We were developing a Java EE application using RichFaces and A4J on the front end. The application was running fine the previous day, and then this happened. It was easy to enough to google “linkage error”, but it was difficult to locate the culprit. The error is often associated with the same JAR being loaded twice, but we checked and double-checked and the application was configured just fine.

So we tried locating where the org.w3c.dom classes were located in the JARs, and it turns out that the culprit was our upgrade of Apache POI.

Solution: For the purposes of enhancing another piece of functionality in our application, we needed to upgrade Apache POI to 3.6, including the JARs for the Open Office XML (OOXML) standards. Using Ant+Ivy, this resolved the dependency on Apache XMLBeans, which was packaged with 4 org.w3c.dom classes.

Naturally, this was what was causing the linkage error, since the WebSphere 7 libraries included an xml.jar, containing these classes. With no fix for the issue, we repackaged xmlbeans.jar by removing the org.w3c.dom classes and placing this repackaged version in our internal repository. After rebuilding the application, this made the errors go away.

This JIRA issue, https://issues.apache.org/jira/browse/XMLBEANS-376, confirms the addition of the org.w3c.dom classes (namely, DOMConfiguration, DOMStringList, TypeInfo, and UserDataHandler) to xmlbeans.jar, but the issue is considered minor. So far, no one from Apache XMLBeans team has confirmed whether they have added special logic in these classes.

Whether they did or they didn’t, it would have been a cleaner solution to not have packaged these classes with the JAR, in the first place.

References: Here are some of the articles / posts I used while researching this puzzler:

  1. The java.lang.LinkageError: loader constraint violation demystified
  2. Debug Your  App – java.lang.LinkageError

Entry Filed under: Agile and Development

2 Comments Add your own

  • 1. swetha  |  October 25th, 2010 at 6:22 am

    hi,
    i have been involved in a code generation tool comprising AndroMDA 3.3, ArgoUML, Maven. I have been successful in the process. By default the UI portion used to generate JSF pages use MyFaces framework. Now, I have been asked to replace MyFaces with RichFaces. On this process, i added richfaces jars to web-inf/lib. When I created a web application with this set up and deployed, I got the following error:

    java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method “org.ajax4jsf.component.AjaxViewRoot$1.invokeContextCallback(Ljavax/faces/context/FacesContext;Ljavax/faces/component/UIComponent V” the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the current class, org/ajax4jsf/component/AjaxViewRoot$1, and the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) for interface javax/faces/component/ContextCallback have different Class objects for the type javax/faces/context/FacesContext used in the signature

    Only then, i came across ur post here. Your post was very clear and precise and m able to understand the origin of this error. But the prob i face is that, the jar containing javax/faces/context/FacesContext class does not exist in my application. And i am not sure which class to delete. javax/faces/context/FacesContext or javax/faces/component/ContextCallback ???

    Awaiting ur reply at the earliest……

  • 2. Via Bulatao  |  October 27th, 2010 at 8:24 am

    Hi Swetha! The colliding JARs may not necessarily be in your application, but it could be in your application server. Have you verified that the JARs installed on your application server do not collide against your application? Against each other? Make sure to check your classloader configuration as well. Good luck!

Leave a Comment

Required

Required, hidden


seven + = 14

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

© 2010-2012 Summa All Rights Reserved -- Copyright notice by Blog Copyright