Troubleshooting
Problem
This document will describe an issue where a "java.lang.VerifyError: JVMVRFY013 class loading constraint violated" error occurs with WebSphere Application Server using IBM Technology for JVM when accessing a WSDL exposed by Axis2.
Resolving The Problem
Problem
When accessing a Web application within WebSphere Application Server using the IBM Technology for JVM and Apache Axis2 framework with an application server/WAR class loader order set to PARENT_LAST, the following error might be encountered:
-
java.lang.VerifyError: class loading constraint violated (class: org/apache/xerces/dom/CoreDocumentImpl method: getDomConfig()Lorg/w3c/dom/DOMConfiguration;) at pc: 0
at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:69) at java.lang.J9VMInternals.verify(J9VMInternals.java:67) at java.lang.J9VMInternals.verify(J9VMInternals.java:67) at java.lang.J9VMInternals.initialize(J9VMInternals.java:131) at org.apache.xerces.parsers.AbstractDOMParser.startDocument(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at javax.xml.parsers.DocumentBuilder.parse(Unknown Source) at org.apache.log4j.xml.DOMConfigurator$2.parse(DOMConfigurator.java:690) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:789) at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:696) at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:471) at org.apache.log4j.LogManager.
(LogManager.java:125) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:196) at org.apache.log4j.Logger.getLogger(Logger.java:118) at com.estesexpress.ws.toolbox.logging.LogWriter. (LogWriter.java:42) at com.estesexpress.ws.toolbox.logging.LogWriter.getInstance(LogWriter.java:72) at com.estesexpress.ws.toolbox.handlers.MyEstesAuthenticationHandler. (MyEstesAuthenticationHandler.java:43) at java.lang.Class.newInstanceImpl(Native Method) at java.lang.Class.newInstance(Class.java:1328) at org.apache.axis2.deployment.util.Utils$3.run(Utils.java:136) at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:132) at org.apache.axis2.deployment.util.Utils.loadHandler(Utils.java:132) at org.apache.axis2.deployment.AxisConfigBuilder.processPhaseList(AxisConfigBuilder.java:533) at org.apache.axis2.deployment.AxisConfigBuilder.processPhaseOrders(AxisConfigBuilder.java:564) at org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuilder.java:147) at org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(DeploymentEngine.java:703) at org.apache.axis2.deployment.WarBasedAxisConfigurator. (WarBasedAxisConfigurator.java:157) at org.apache.axis2.transport.http.AxisServlet.initConfigContext(AxisServlet.java:525) at org.apache.axis2.transport.http.AxisServlet.init(AxisServlet.java:443) at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:235) at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.init(ServletWrapper.java:342) at com.ibm.ws.webcontainer.servlet.ServletWrapper.initialize(ServletWrapper.java:1375) at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.initialize(ServletWrapper.java:175) at com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.createServletWrapper(WebExtensionProcessor.java:99) at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:910) at com.ibm.ws.webcontainer.webapp.WebApp.getServletWrapper(WebApp.java:832) at com.ibm.ws.webcontainer.webapp.WebApp.initializeTargetMappings(WebApp.java:550) at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:387) at com.ibm.ws.wswebcontainer.webapp.WebApp.initialize(WebApp.java:293) at com.ibm.ws.wswebcontainer.webapp.WebGroup.addWebApplication(WebGroup.java:93) at com.ibm.ws.wswebcontainer.VirtualHost.addWebApplication(VirtualHost.java:162) at com.ibm.ws.wswebcontainer.WebContainer.addWebApp(WebContainer.java:673) at com.ibm.ws.wswebcontainer.WebContainer.addWebApplication(WebContainer.java:626) at com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:335) at com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:551) at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1274) at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1137) at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:573) at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:816) at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:945) at com.ibm.ws.runtime.component.ApplicationMgrImpl$AppInitializer.run(ApplicationMgrImpl.java:2120) at com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:342) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1551)
A PARENT_LAST class loader order also known as Classes loaded with local class loader first or Application first is defined as the following:
"The PARENT_LAST" class loader mode causes the class loader to attempt to load classes from it local class path before delegating the class loading to it parent. Using this policy, an application class loader can override and provide its own version of a class that exists in the parent class loader."
Note: The issue does not occur if the parent-delegation model is set to PARENT_FIRST.
As part of the IBM Technology for JVM new class loading mechanism with a parent-delegation model, class loading loads, verifies, prepares, resolves, and initializes a class from a Java class file.
| o | Loading involves obtaining the byte array representing the Java class file. |
| o | Verification of a Java class file is the process of checking that the class file is structurally well-formed and then inspecting the class file contents to ensure that the code does not attempt to perform operations that are not permitted. |
| o | Preparation involves the allocation and default initialization of storage space for static class fields. Preparation also creates method tables, which speed up virtual method calls, and object templates, which speed up object creation. |
| o | Initialization involves the processing of the class's class initialization method, if defined, at which time static class fields are initialized to their user-defined initial values (if specified). |
Note: The IBM Classic JVM uses a different class loading policy and model. Because of this, the issue described in this document will not occur with the Classic JVM. The Classic JVM could be used as a work-around; however, it can be used only on a temporary basis because it is no longer available beginning at IBM i 7.1 OS.
In this case, an error occurs during the verification step of the class loading process. The java.lang.VerifyError is a subclass of a java.lang.LinkageError. A VerifyError is thrown when the "verifier" detects that a class file, though well formed, contains some sort of internal inconsistency or security problem. Subclasses of the LinkageError indicate that a class has some dependency on another class; however, the latter class is incompatible after the compilation of the former class.
If this verbiage is related to the exception above, the error starts to make more sense. The exception indicates we are loading the same classes (org/apache/xerces/dom/CoreDocumentImpl and org/w3c/dom/DOMConfiguration) with two different class loaders (JDK and Application (WAR) classloaders); however, a referenced class (org/w3c/dom/Notation) is only loaded by one of them (JDK class loader). The org/apache/xerces/dom/CoreDocumentImpl class references the org/w3c/dom/DOMConfiguration class which then references the org/w3c/dom/Notation class. When the application creates its own org/apache/xerces/dom/CoreDocumentImpl and org/w3c/dom/DOMConfiguration instances, it will load the classes from the WAR class loader path (because of the "PARENT_LAST" policy). The class org/w3c/dom/Notation is loaded by the JDK class loader since it does not exist in any of the Jars or classes included in the WAR class loader path. Then, the application would attempt to pass an instance of the JDK org/w3c/dom/Notation class to the WAR instance of org/w3c/dom/DOMConfiguration, which can only accept an instance of the WAR version of the org/w3c/dom/Notation class. This results in the java.lang.VerifyError.
Resolution
Ultimately, an issue is seen where the Apache Axis2 product packaged with the WAR file contains a XmlBeans library (xmlbeans-2.3.0.jar) with a set of interfaces in the org.w3c.dom package that may cause issues with class loaders using a PARENT_LAST class loading policy. These interfaces reference other Java classes which are loaded by the JDK class loader and not by the WAR class loader as expected. To avoid the issue, the Apache Axis2 version either needs to be updated to the latest specification, and you must remove the XmlBeans library (xmlbeans-2.3.0.jar) from the Axis2 WAR, or remove the content of the org.w3c.dom package from the XmlBeans library.
For more information related to the Apache Axis2/Java project and to obtain the latest specification release, you should refer to the following URL:
//axis.apache.org/axis2/java/core/
Historical Number
618571504
Was this topic helpful?
Document Information
Modified date:
18 December 2019
UID
nas8N1011249