Page History

...

JBoss

...

If you package the war in the ear, you might need to add the jboss specific file (jboss-app.xml) in the $EAR/META-INF folder to config the classloader.

...

<?xml version="1.0" encoding="UTF-8"?>
<jboss-app>
	<loader-repository>
		apache.cxf:loader=spring_http.ear
		<loader-repository-config>
			java2ParentDelegation=false
		</loader-repository-config>
	</loader-repository>
</jboss-app>

Application Server

JBoss Application Server (JBoss AS) comes with its own webservices stack (JBossWS) in order for providing full JavaEE support.
Starting from JBoss AS 6 M4, the default webservices stack is internally based on Apache CXF; as a consequence users might experiment classloading issues with classes from both the CXF libraries and its dependencies if included in deployments and not properly isolated. Please refer to the relevant JBoss AS documentation for details on how to turn on classloading isolation on the application server version in use.

In particular, when willing to run Apache CXF based applications on top of JBoss AS 7 series, users have basically two options:

• use JBoss AS as if it was a servlet container with no WS functionalities: this basically implies disabling the webservices subsystem for the user deployment, hence preventing the AS webservices stack from processing the ws endpoint deployment and letting the CXF libs included in the archive deal with any WS invocations when CXFServlet is hit; the webservices subsystem is turned off by adding a jboss-deployment-descriptor.xml as follows to the ws endpoint deployment:

  Code Block
  xml xml
  <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <deployment> <exclude-subsystems> <subsystem name="webservices" /> </exclude-subsystems> </deployment> </jboss-deployment-structure>

  this approach offers the fastest route to deploying CXF apps on JBoss AS; the drawback is that no special ws integration with JBoss AS internals is available

• rely on JBossWS integration and the Apache CXF libraries included in the application server (documentation): this implies removing any Apache CXF libs from the ws deployment as well as any other dependencies which is already included in JBoss AS (including any Java EE API jar); if included, the optional web.xml descriptor is to be rewritten according to JBossWS convention (see documentation); the Spring support is optional in JBoss AS and Spring based endpoint declaration is not the default/preferred configuration approach for ws endpoints, hence users willing to declare endpoints using Spring needs to create a org.springframework.spring module and put their endpoint declarations in a jbossws-cxf.xml descriptor; if the user application makes use of any lib besides tha JavaEE api, proper module dependencies are to be declared either using the jboss-deployment-structure.xml descriptor or the archive MANIFEST.MF (few directions on ws modules available here)

The second approach allows leveraging the full JavaEE 6 stack (including e.g. JSR-109) as well as specific ws integration with JBoss AS internals.If you are coming across LinkageErrors involving the QName class, try repackaging the stax-api jar without the javax.xml.namespace.QName class.  (In JBoss 4.0.5GA at least) a conflicting version of this class is included in JBoss's lib and lib/endorsed directories.  This was the only way I could get CXF working in my environment.

WebLogic

There are two ways to deploy a CXF WAR archive in WebLogic. (Note: This has been validated on WebLogic9.2.)

...

Follow the PDF download given within this IBM developerWorks article:http://www.ibm.com/developerworks/websphere/library/techarticles/1001_thaker/1001_thaker.html^{Image Removed}

As described in the PDF, you'll need to change the Classloader order to "Classes loaded with local class loader first (parent last)" and to disable the IBM web services engine, either for the JVM as a whole or for the particular module.

...

Another issue that comes up with certain versions of WebSphere is an incompatibility with the SAAJ implementation. It is recommended to use the org.apache.servicemix.bundles.saaj-impl-1.3.18_1.jar saaj impl available from http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.saaj-impl/1.3.18_1/^{Image Removed} as that contains a recent version of SAAJ along with it's required DOM implementation which will work on the IBM JDK.

...

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE sun-web-app PUBLIC '-//Sun Microsystems, Inc.//DTD 
Application Server 9.0 Servlet 2.5//EN' 
'http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd'> 
<sun-web-app> 
<class-loader delegate="false"/> 
</sun-web-app>

OC4J

...

Try something simple. Download OC4J standalone and bootstrap it from command line directly: {{java \[options\] \-jar oc4j.jar}}. Enable [SAX debugging| http://java.sun.com/javase/6/docs/api/javax/xml/parsers/SAXParserFactory.html#newInstance()]. Be sure You don't include douplicated jars in Your application like {{xercesImpl, xalan, xml-apis and geronimo-ws-metadata_2.0_spec-1.1.1.jar}}. Review steps above once more. It works ;-) .

Integration with Application Server FAQ

...