The web services engine uses the XML parser classes that
comes in WebSphere Application Server. When a customer bundles their XML
parser classes, this will cause problems with the web services engine. In
this scenario, the web services engine will try to load classes that the
customer bundled. This is a known limitation, and can occur in many
situations:
1) A customer has a EAR file with a web service, and has Xerces and
Xalan jar files inside that EAR file
2) A customer has two EAR files - one with a web service (EAR1) and one
without a web service (EAR2). If EAR1 contains XML parser classes, this
may cause the ClassCastException with EAR2, even though they are separate
EAR files.
The following exceptions may appear in the SystemOut.log:
java.lang.ClassCastException:
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source)
at
com.ibm.ws.webservices.engine.utils.XMLUtils.getDOMFactory(XMLUtils.java
:363)
...
This is a product limitation and NOT a defect. In the runtime and web
container, you can supply your own custom XML parser. However, the issue
is with the classloading interaction between the Web services engine XML
parser classes and your application-supplied parser.
In the runtime, we resolve this problem by using a parser factory utility
that always uses the parser classes loaded by the ExtClassLoader (by
switching the context classloader). The webcontainer also has issues like
this and resolves them by switching the context classloader at the
appropriate time. However, the WebServices Engine cannot implement this
solution to resolve the problems because they have issues switching the
context classloader.
|