http://xerces.apache.org/xerces2-j/faq-general.html#faq-4

http://xml.apache.org/xalan-j/faq.html#faq-N100D6

The only correct scenarios are:

• JDK 1.4: adding an XML implementation (xml-apis + xercesImpl or Sun's JAXP) to an endorsed directory, manually in <jre>/lib/endorsed and by adding a new directory for the service wrapper when starting Mule as server

• JDK 1.5: by default no action necessary, though users MAY install an updated JAXP (see http://jaxp.dev.java.net/) in <jre>/lib/endorsed to update SAX/DOM or gain the new StAX capabilities introduced in JAXP 1.4 and shipping with JDK 1.6

• JDK 1.6: no action necessary, and even though users MAY install an updated JAXP (see above) it is most likely not necessary as JAXP 1.4 revisions usually trail JDK 1.6 releases.

An interesting corner case is our dependency on woodstox, which is not necessary when running on JDK 1.6 (as StAX is built in there); the good news is that there are no conflicts since the package names are completely different and therefore the discovery process does not get confused as with SAX/DOM. So woodstox can remain on the classpath for all JDKs, both when necessary (JDK 1.4/1.5 without endorsed JAXP 1.4) and redundant but harmless (JDK 1.6).

In any case, the bottom line is that regardless of JDK used for building or deploying, there must not be any xml-apis or xerces on the classpath, no matter what version. This makes checking for classpath violations very easy.