Edit Question - KnowledgeHub

Title Body

The environment is WAS 6.1 on Linux, deploying a webapp that uses classes from xercesImpl.jar. Due to company policy restrictions, the app must be deployed with settings: Class Loader Order Classes loaded with parent class loader first -> Classes loaded with application class loader first WAR class loader policy Class loader for each WAR file in application -> Single class loader for application The WAR file contains a copy of xercesImpl.jar, the same one that was in the classpath when the app was compiled. When launching the webapp, when Spring tries to parse its configs, it throws: java.lang.VerifyError: class loading constraint violated (class: org/apache/xerces/jaxp/DocumentBuilderImpl method: parse(Lorg/xml/sax/InputSource;)Lorg/w3c/dom/Document;) ANALYSIS SO FAR It appears that WAS provides an implementation of org.apache.xerces.jaxp.DocumentBuilderImpl, because we can remove xercesImpl.jar from the WAR file and still get the same error (not ClassNotFoundException). Thus WAS seems to be resolving the references using its own copy that is incompatible with the references in our compiled class files. However, the only other instance of 'xercesImpl.jar' I can find (other than the copy deployed with our app) is in directory deploytool , which seems to be outside the app server. I scanned all the jars in WAS (all 1300 of them) with for i in `find . -name \*.jar`; do jar tvf $i|grep -qi xerces && echo $i ; done and found that ./java/jre/lib/xml.jar contains all the classes in org.apache.xerces.* , so this is likely where the classloader is resolving the reference. HERE'S THE WEIRD PART: If we change to "parent class loader first" we do not see the exception. This goes counter to the expected behavior. We would expect that with "application cl

Tags (comma-separated) Cancel