Here's our solution:
Now for the story...
<!-- Batik Stuff -->
We recently implemented the Batik libraries into a web application that will be run on WebSphere 7. We are also using Apache CXF for client-side webservice communication. Because of cxf, we need to use the parent-last classloading options.
It works fine in our Tomcat development environments but when we deploy the EAR to WebSphere, it dies horribly with:
java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl incompatible with javax.xml.parsers.DocumentBuilderFactory
Digging through the stacktrace, it was having difficulties with our log4j because it couldn't load the properties (log4j.xml). This is not a log4j issue but an issue trying to parse the log4j.xml. (I replaced it with a .properties file and the webapp died trying to parse applicationContext.xml.)
If you pull in Batik using Maven, you'll find out that it has a dependency on xml-apis 1.3.04.
The thing is, this dependency is out of date and has been rolled into Java.
Apparently, Sun/Oracle likes to occasionally incorporate the Apache xml libraries into the JVM.
By specifying parent-last for classloading, Websphere will use this jar instead of what is in Java for the javax.xml.parsers.DocumentBuilderFactory interface. We really want to default to Websphere when it comes to parsing xml files so we need to remove this dependency from our project and let it pick up what Websphere wants to use.
Thus, the solution at the top.
- All about JAXP
Hopefully, posting this will save someone else some classloader headaches.