jaxen

IncompatibleClassChangeError due to throws clauses not matching between JaxenHandler and XPathHandler

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.1
  • Fix Version/s: 1.1
  • Component/s: saxpath
  • Labels:
    None
  • Environment:
    Windows
  • Number of attachments :
    0

Description

Following exception occurs intermittently:

Uncaught exception
java.lang.IncompatibleClassChangeError: Class org.jaxen.JaxenHandler does not
implement the requested interface org.jaxen.saxpath.XPathHandler
at org.jaxen.saxpath.base.XPathReader.parse(XPathReader.java:98)

The line is:

getXPathHandler().startXPath();
in XPathReader.parse.

We have debugged a similar error in other code previously. The error is caused by the throws clauses not matching between the implementation and the interface (JaxenHandler implementing XPathHandler). In the particular call the startXPath method is defined by the interface to throw a SAXPathException and the implementation throws no exception. It appears all of the methods in JaxenHandler are inconsistent either throwing nothing or throwing a JaxenException.
Even though this is an intermittant issue it should be corrected. Once it appears there seems to be a tendency for the user to see it many times over. The user has to restart their application before they can resume what they are working on.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brian Ewins added a comment -

That exception isn't caused by what you describe. If it was, you'd see it all the time - its very common to have code like this. For example, look at ByteArrayInputStream's read methods versus the ones in InputStream. You might /appear/ to resolve the situation by adding the throws clause and recompiling, but more likely it was just the act of a fresh compile that fixed the bug.

The exception is caused by loading incompatible versions of a class; in other words, a different version of jaxen, or one compiled with a different version of javac. You don't describe the specific environment in which you saw this problem, but I'm 99% certain you're looking at an appserver which has more than one copy of jaxen (or saxpath) sitting around, and some lack of isolation in your classloaders is causing your grief.

A common cause of this exception (for all kinds of code) used to be the work directory in tomcat needing cleaned out.

Show
Brian Ewins added a comment - That exception isn't caused by what you describe. If it was, you'd see it all the time - its very common to have code like this. For example, look at ByteArrayInputStream's read methods versus the ones in InputStream. You might /appear/ to resolve the situation by adding the throws clause and recompiling, but more likely it was just the act of a fresh compile that fixed the bug. The exception is caused by loading incompatible versions of a class; in other words, a different version of jaxen, or one compiled with a different version of javac. You don't describe the specific environment in which you saw this problem, but I'm 99% certain you're looking at an appserver which has more than one copy of jaxen (or saxpath) sitting around, and some lack of isolation in your classloaders is causing your grief. A common cause of this exception (for all kinds of code) used to be the work directory in tomcat needing cleaned out.
Hide
Permalink
Agnes Freese added a comment -

We are absolutely, positively, 100% sure that this is the cause of the problem. There is only one jaxen library in the classpath.

We have debugged the same problem within our internal code and once the throws clauses were fixed that issue has not been seen in over a year. This is the reason for the exception.

It may be that people have been coding in this way and it works.. most of the time. But there appears to be some problem that comes up intermittently when the interface throws clause does not match the implementation. It took us a long time to track the issue we had in our code down.

If it is not fixed within the jaxen code we will have to fix it externally. It absolutely is the probem.

Show
Agnes Freese added a comment - We are absolutely, positively, 100% sure that this is the cause of the problem. There is only one jaxen library in the classpath. We have debugged the same problem within our internal code and once the throws clauses were fixed that issue has not been seen in over a year. This is the reason for the exception. It may be that people have been coding in this way and it works.. most of the time. But there appears to be some problem that comes up intermittently when the interface throws clause does not match the implementation. It took us a long time to track the issue we had in our code down. If it is not fixed within the jaxen code we will have to fix it externally. It absolutely is the probem.
Hide
Permalink
Brian Ewins added a comment -

I'm not convinced. That throws clause was removed after the tag V11_BETA_8. You will get this exception if you have a version of jaxen from before that tag with the current jaxen.

Note that jaxen may not simply be called jaxen-VERSION.jar. Other xml libraries bundle jaxen /in their jar/. IIRC this has been the case in the past for dom4j and maybe xom (Elliotte, can you remember the details of this one?). I know that around the time of that tag, dom4j were discussing unbundling jaxen, which makes me suspicious that that is the culprit.

Show
Brian Ewins added a comment - I'm not convinced. That throws clause was removed after the tag V11_BETA_8. You will get this exception if you have a version of jaxen from before that tag with the current jaxen. Note that jaxen may not simply be called jaxen-VERSION.jar. Other xml libraries bundle jaxen /in their jar/. IIRC this has been the case in the past for dom4j and maybe xom (Elliotte, can you remember the details of this one?). I know that around the time of that tag, dom4j were discussing unbundling jaxen, which makes me suspicious that that is the culprit.
Hide
Permalink
Brian Ewins added a comment -

A couple more suspects: findjar.com suggests that jaxen has been bundled in the pxe and groovy-soap projects as well.

Show
Brian Ewins added a comment - A couple more suspects: findjar.com suggests that jaxen has been bundled in the pxe and groovy-soap projects as well.

People

  • Assignee:
    Unassigned
    Reporter:
    Agnes Freese
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: