FULL PRODUCT VERSION :
java version "1.6.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-beta-b59)
Java HotSpot(TM) Client VM (build 1.6.0-beta-b59, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
In Java 5, Sun repackaged the Xerces they used internally by the JRE/JDK to provide the default JAXP factory implementations so that customers can use their own Xerces and Xalan versions without conflicting with that used by the JRE/JDK.

Unfortunately, in Java 6, Sun has included a set of META-INF/services/org.apache.* entries (and in particular here META-INF/services/org.apache.xerces.xni.* entries) in resources.jar. Unless these are removed one cannot use one's own Xerces version (2.7.1 in my case, but the problem is general). This is true because the other Xerces version will still see these entries and try to use the repackaged Sun classes noted therein, which obviously are not instances of the appropriate interfaces from the other (non-repackaged) Xerces version. This results in stack traces like the following.

java.lang.ClassCastException: com.sun.org.apache.xerces.internal.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
        ...

Not only can one not use a particular Xerces version of choice, but this also means that any legacy code that directly references/expects non-repackaged Xerces classes is out-of-luck!

I have repackaged Xalan myself in the past and thus can definitively say that the solution is to repackage the META-INF/services/org.apache.* resources, i.e. rename the entries (and their references from the code) via a naming pattern similar to that used for renaming the Xerces and Xalan class files.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Attempt to use one's own non-repackaged Xerces version. See description.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No exception and successful use of the external Xerces as per Java 5 (and previous Java versions for that matter).
ACTUAL -
A cacophany of ClassCastExceptions for various attempts to create Xerces parsers, etc.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exceptions like that shown above (and repeated here):

java.lang.ClassCastException: com.sun.org.apache.xerces.internal.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
        ...


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Virtually any use of an external Xerces SAXParser should do as long as one does not explicitly force the particular XNI level implementation.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I suspect one could rip these entries out of resources.jar (as they're not in the Xerces distribution jars) and let the internal Xerces implementation revert to its defaults. That's not really a solution, though. Also it does not allow one to override these settings separately from those used by a non-repackaged Xerces. Thus as long as Xerces and Xalan are repackaged one must also repackage any/all associated META-INF/services entries!

Release Regression From : 5.0
The above release value was the last known release where this
bug was known to work. Since then there has been a regression.