This document provides configuration information required for your Application Server to run Apache Axis2 to its fullest potential.
We recommend using the exploded configuration to deploy Axis2 WAR in WebLogic application server to support the hotupdate/ hotdeployment features in Axis2. However, if you want to deploy custom WARs, say in a clustering environment, you need to add two additional files into the WEB-INF named "services.list" and "modules.list" under the modules and services directory respectively.
WebLogic ships with JARs that conflict with JARs present in Axis2. Therefore use <prefer-web-inf-classes> to ensure that JARs packaged in Axis2 WAR are picked up from WEB-INF/lib. You can do this by setting the <prefer-web-inf-classes> element in WEB-INF/weblogic.xml to true. An example of weblogic.xml is shown below:
<weblogic-web-app> <container-descriptor> <prefer-web-inf-classes>true</prefer-web-inf-classes> </container-descriptor> </weblogic-web-app>
If set to true, the <prefer-web-inf-classes> element will force WebLogic's classloader to load classes located in the WEB-INF directory of a Web application in preference to application or system classes. This is a recommended approach since it only impacts a single Web module.
Please refer to the following documents in WebLogic for more information:
BEA WebLogic Server 9.0 comes with its own StAX implementation. This results in lack of namespacing on serialised items. In turn, WebLogic server (WLS) breaks with AXIOM on the WLS classpath. Hence a filtering classloader is required:
Adding the following to weblogic-application.xml should resolve this issue:
<prefer-application-packages> <package-name>com.ctc.wstx.*</package-name> <package-name>javax.xml.*</package-name> <package-name>org.apache.*</package-name> </prefer-application-packages>
Note that the libraries listed--Xerces, StAX API, Woodstox--need to be on the application classpath.
The JAX-WS runtime in WebSphere Application Server is based on a modified version of Axis2 and these classes are visible to application class loaders. This means that when deploying a standard version of Axis2 on WAS 7.0 (and WAS 6.1 with the Web Services feature pack installed), special configuration is required to avoid conflicts with the Axis2 classes used internally by WebSphere. In particular it is necessary to change the class loader policy of the Web module to parent last. However, this is not sufficient because Axis2 creates additional class loaders for modules and services, and these use parent first class loading by default. Therefore, two things must be done to make a standard Axis2 distribution work with WebSphere:
By default (i.e. if the Distribute application option has not been disabled explicitly) WebSphere will deploy the application in exploded form. The standard location for these files is in the installedApps subdirectory in the WebSphere profile directory. This means that AAR and MAR files can simply be deployed by dropping them into the corresponding folders. In this scenario, hot deployment is supported and there is no need to update the services.list and modules.list files.
However, the directory is still under control of WebSphere and manually deployed AAR and MAR files will be removed e.g. when the application is upgraded. It may therefore be a good idea to configure Axis2 to use a repository location outside of the installedApps directory.
The instructions given above apply to Axis2 1.5.5 or higher. Older versions don't support the EnableChildFirstClassLoading parameter, and we don't provide any support for deploying these versions on WAS 6.1 (with the Web Services feature pack installed) or 7.0. However, IBM has published a technote with an alternative approach that may work for older Axis2 versions.
On some WAS versions the following error may occur, e.g. when accessing a WSDL exposed by Axis2:
java.lang.VerifyError: JVMVRFY013 class loading constraint violated; class=org/apache/xerces/dom/CoreDocumentImpl, method=getDomConfig()Lorg/w3c/dom/DOMConfiguration
This is caused by the XmlBeans library packaged with Axis2. This library contains a set of interfaces in the org.w3c.dom package and this may cause issues with class loaders that don't use a simple parent-first policy. To avoid this issue, upgrade your WAS to a more recent fix pack level, remove the XmlBeans library from the Axis2 WAR or remove the content of the org.w3c.dom package from the XmlBeans library.