CODEWITHSUNDEEP
javaweblogicclassloaderxercesopensaml
Johann Goulley
Johann Goulley

Reputation: 415

Conflicts between JDK6 and xml-apis

After upgrading OpenSAML from 1.1 to 2.6.1, which needs xerces-impl dependency, the following stack appears on startup :

 Caused by: java.lang.ClassCastException: org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl cannot be cast to javax.xml.datatype.DatatypeFactory
       at javax.xml.datatype.DatatypeFactory.newInstance(DatatypeFactory.java:131) ~[xml-apis-1.4.01.jar:1.6.0_45]
       at com.sun.xml.bind.DatatypeConverterImpl.<clinit>(DatatypeConverterImpl.java:831) ~[glassfish.jaxb_1.0.0.0_2-1-12.jar:2.1.12]
       ... 68 common frames omitted

xerces-impl redefine some jre classes and comes with xml-apis which redefine some jre interfaces. org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl come from xerces-impl.

I'm on weblogic 10.3.5 and JDK 6.

I read Dealing with "Xerces hell" in Java/Maven? and try to exclude xml-apis but xerces-impl throws NoClassDefFoundError. Copying xml-apis and xerces-impl in jre/lib/endorsed throws ClassCastException too (http://docs.oracle.com/javase/6/docs/technotes/guides/standards/).

Adding -Djavax.xml.datatype.DatatypeFactory=com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl on startup command throws :

 Caused by: java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory
    at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128) ~[xml-apis-1.4.01.jar:1.6.0_45]
    at javax.xml.bind.helpers.AbstractUnmarshallerImpl.getXMLReader(AbstractUnmarshallerImpl.java:80) ~[na:1.6.0_45]

Then adding -Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl throws :

 Caused by: java.lang.ClassCastException: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory
    at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
    at ch.qos.logback.core.joran.event.SaxEventRecorder.buildSaxParser(SaxEventRecorder.java:79)

I don't know what to do next. Any idea ?

Upvotes: 2

Views: 5372

Answers (2)

Johann Goulley
Johann Goulley

Reputation: 415

In addition to javax.xml.bind as prefer-application

<wls:package-name>javax.xml.bind.*</wls:package-name>

in weblogic.xml, adding jaxb dependencies solved my problem :

<dependency>
    <groupId>com.sun.xml.bind</groupId>
    <artifactId>jaxb-impl</artifactId>
    <version>${jaxb-impl.version}</version>
</dependency>
<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>${jaxb-api.version}</version>
</dependency>

Upvotes: 0

user944849
user944849

Reputation: 14971

WebLogic includes its own versions of a lot of these libraries on the classpath, & they can interfere with your app. Try adding a section like this to the weblogic.xml file:

<weblogic-web-app>

  <container-descriptor>
    <prefer-application-packages>
        <package-name>org.slf4j.*</package-name>
        <package-name>org.slf4j.helpers.*</package-name>
        <package-name>org.slf4j.impl.*</package-name>
        <package-name>org.slf4j.spi.*</package-name>
    </prefer-application-packages>
  </container-descriptor>
  ...
</weblogic-web-app>

The example shows the packages for slf4j; I'm not sure what they will be for xerces. If you have access to the wls-cat tool, that should help figure it out.

Update

Classpath conflicts between WLS and your app may be fixed in one of three ways.

  1. Add the package to the <prefer-application-packages> element so the app's take precedence
  2. Change the POM to note that a particular dependency is provided by WLS
  3. Exclude the dependency from the POM entirely.

I suggest using mvn dependency:tree with the former version of OpenSAML, note the dependencies. Then change to the new OpenSAML version, & note what new dependencies are pulled in. Take a look at the WLS server's modules directory to see what libraries WLS is using, cross-reference this with the changed dependencies with the new OpenSAML version, and decide which of the 3 possibilities seems to be the best fit. For example, if you can see that WLS uses an earlier version of a lib than your app does, you probably want to use option 1. Do this until you can get the app to deploy, then use wls-cat to finish the job.

Upvotes: 1

Related Questions