title: WAS 6.1 java.lang.VerifyError: class loading constraint violated
body: <p>The environment is WAS 6.1 on Linux, deploying a webapp that uses
  classes from xercesImpl.jar.</p>
  
  <p>Due to company policy restrictions, the app must be deployed with
  settings:</p>
  
  <pre><code>Class Loader Order
      Classes loaded with parent class loader first
  -&gt;  Classes loaded with application class loader first
  
  WAR class loader policy
      Class loader for each WAR file in application
  -&gt;  Single class loader for application
  </code></pre>
  
  <p>The WAR file contains a copy of xercesImpl.jar, the same one that
  was in the classpath when the app was compiled.</p>
  
  <p>When launching the webapp, when Spring tries to parse its configs, it
  throws:</p>
  
  <pre><code>java.lang.VerifyError: class loading constraint violated 
      (class: org/apache/xerces/jaxp/DocumentBuilderImpl 
      method: parse(Lorg/xml/sax/InputSource;)Lorg/w3c/dom/Document;)
  </code></pre>
  
  <p>ANALYSIS SO FAR</p>
  
  <p>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
  <code>deploytool</code>, which seems to be outside the app server.</p>
  
  <p>I scanned all the jars in WAS (all 1300 of them) with</p>
  
  <pre><code>for i in `find . -name \*.jar`; do jar tvf $i|grep -qi xerces &amp;&amp; echo $i ; done
  </code></pre>
  
  <p>and found that <code>./java/jre/lib/xml.jar</code> contains all the classes in <code>org.apache.xerces.*</code>,
  so this is likely where the classloader is resolving the reference.</p>
  
  <p>HERE'S THE WEIRD PART:</p>
  
  <p>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 classloader first" it would use the xercesImpl.jar that we
  provided, and use WAS's version only if we set "parent classloader
  first".  This appears to be backwards from what we actually see.</p>
  
  <p>THE QUESTION:</p>
  
  <p>How is the classloader delegation setting interacting with the above information to result in the observed behavior?</p>