Home/ Questions/Q 4013670
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T09:24:02+00:00

I’m having a strange problem when trying to run a maven build that uses

  • 0

I’m having a strange problem when trying to run a maven build that uses the jaxb2 plugin to do JAXB codegen (see stacktrace below). The best that I can figure is that there’s some implementation of DTMManager that’s being class loaded from a different JAR than the one in xalan-2.7.1; however, I have verified that the classpath that is used for running the jaxb:generate goal only has the one xalan-2.7.1.jar that contains a DTMManager or a DTMManagerDefault – so I have no clue what else might be getting in the way.

One final data point: our build specifies a ‘snapshot’ profile, which really only serves to also JAR up the sources (using maven-source-plugin) and publish them as artifacts. The failure scenario I described above only occurs when this profile is specified in addition to the default.

I’m using Maven 2.2.1 running on Sun’s 64-bit JDK 1.6.0_21 on Linux x64 (Fedora 13) – see below the stacktrace for the ‘mvn -v’ info.

Any ideas on what the problem may be and/or how to go about debugging it? This has been causing me grief for the past few days and it’s now blocking progress 🙁

java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault cannot be cast to org.apache.xml.dtm.DTMManager
    at org.apache.xml.dtm.DTMManager.newInstance(DTMManager.java:137)
    at org.apache.xpath.XPathContext.<init>(XPathContext.java:102)
    at org.apache.xpath.jaxp.XPathImpl.eval(XPathImpl.java:207)
    at org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:281)
    at com.sun.tools.xjc.reader.internalizer.Internalizer.buildTargetNodeMap(Internalizer.java:224)
    at com.sun.tools.xjc.reader.internalizer.Internalizer.buildTargetNodeMap(Internalizer.java:289)
    at com.sun.tools.xjc.reader.internalizer.Internalizer.transform(Internalizer.java:134)
    at com.sun.tools.xjc.reader.internalizer.Internalizer.transform(Internalizer.java:96)
    at com.sun.tools.xjc.reader.internalizer.DOMForest.transform(DOMForest.java:448)
    at com.sun.tools.xjc.ModelLoader.buildDOMForest(ModelLoader.java:342)
    at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:374)
    at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:167)
    at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:113)
    at org.jvnet.jaxb2.maven2.XJC2Mojo.runXJC(XJC2Mojo.java:1119)
    at org.jvnet.jaxb2.maven2.XJC2Mojo.execute(XJC2Mojo.java:720)
...

mvn -v:

# mvn -v
Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
Java version: 1.6.0_21
Java home: /usr/java/jdk1.6.0_21/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.33.3-85.fc13.x86_64" arch: "amd64" Family: "unix"
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The solution is to search for all dependencies on Xalan and xercesImpl in the classpath . These dependencies should be excluded.

    Updated

    I found an answer like this – see http://www.mail-archive.com/dev@qpid.apache.org/msg07295.html

    Had a look at this closely and figured it was due to a classpath class
due to Sun bundling an older version of Xalan jar.
I have disabled this test until we come up with a decent solution.

Rajith
    • 0