DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
This document provides app server-specific configuration information for running Apache CXF.
| Table of Contents | ||||
|---|---|---|---|---|
|
JBoss 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-
descriptorstructure.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.
SpringBoot
Please see CXF SpringBoot documentation.
JAX-WS: see JAX-WS Spring Boot demo.
JAX-RS: see JAX-RS Spring Boot and JAX-RS Spring Boot Scan demos.
WebLogic
There are two ways to deploy a CXF WAR archive in WebLogic. (Note: This has been validated on WebLogic9.2.)
...
Pack war in an ear, deploy the ear with weblogic-application.xml
Create a standard J2EE application.xml file in the META-INF folder. (Take $CXF_HOME/samples/java_first_spring_support for example)
Code Block xml xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd"> <application> <display-name>spring_http</display-name> <module> <web> <web-uri>spring_http.war</web-uri> <context-root>spring</context-root> </web> </module> </application>
Create a weblogic-application.xml (Weblogic specific) in the META-INF folder.
Code Block xml xml <?xml version="1.0" encoding="UTF-8"?> <weblogic-application xmlns="http://www.bea.com/ns/weblogic/90"> <application-param> <param-name>webapp.encoding.default</param-name> <param-value>UTF-8</param-value> </application-param> <prefer-application-packages> <package-name>javax.jws.*</package-name> </prefer-application-packages> </weblogic-application>
...
- In the WAS console navigate to Environment > Shared Libraries
- Select the scope you wish your library should be visible in
- Click New and set values ex:
name=MYAPP_SHARED_LIB, classpath=PATH_TO/wsdl4j-1.6.2.jarand Save Navigate to *Application servers > \ [your server name\]* *> Java and Process Management > Class loader > New*Wiki Markup - Select Classes loaded with application class loader first and Save
- Select your new class loader and click Shared library references
- Add your shared library (MYAPP_SHARED_LIB) Save and restart your server.
Tested in WAS 6.1 only but should work in earlier versions as well.
...
One user has reported that he was able to get CXF working on WebSphere with a minimal set of CXF jars by following the above
procedures and using the list of jars:
| Code Block |
|---|
FastInfoset-1.2.9.jar
aopalliance-1.0.jar
commons-logging-1.1.1.jar
cxf-2.5.2.jar
geronimo-activation_1.1_spec-1.1.jar
geronimo-annotation_1.0_spec-1.1.1.jar
geronimo-javamail_1.4_spec-1.7.1.jar
geronimo-jaxws_2.2_spec-1.1.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
geronimo-ws-metadata_2.0_spec-1.1.3.jar
jars_in_war.txt
jaxb-api-2.2.3.jar
jaxb-impl-2.2.4-1.jar
neethi-3.0.1.jar
org.apache.servicemix.bundles.saaj-impl-1.3.18_1.jar
spring-aop-3.0.6.RELEASE.jar
spring-asm-3.0.6.RELEASE.jar
spring-beans-3.0.6.RELEASE.jar
spring-context-3.0.6.RELEASE.jar
spring-core-3.0.6.RELEASE.jar
spring-expression-3.0.6.RELEASE.jar
spring-web-3.0.6.RELEASE.jar
stax2-api-3.1.1.jar
woodstox-core-asl-4.1.1.jar
wsdl4j-1.6.2.jar
xmlschema-core-2.0.1.jar
|
...
CXF Interceptors will not work in Glassfish without this sun-web.xml file to configure the classloader. By default, Glassfish will use Metro for JAX-WS services so the classloader needs to be configured to allow CXF libraries to provide JAX-WS services. The following sun-web.xml xml source was added to /WEB-INF to resolve this issue:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<?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>
|
...
- xercesImpl.jar (from Xerces distribution)
- xml-apis-1.2.02.jar (from CXF-distribution)
- xalan-2.7.0.jar (ditto)
geronimo-ws-metadata_2.0_spec-1.1.1.jar (ditto)
Note When building Your application DO NOT INCLUDE THOSE COMPONENTS again.
...
- unpack
oc4j.jarfile - locate
META-INF/boot.xmlfile and edit it - find section
| Code Block | ||||
|---|---|---|---|---|
| ||||
<!-- WS jax-rpc -->
<code-source path="${oracle.home}/webservices/lib/jaxr-api.jar"/>
<code-source path="${oracle.home}/webservices/lib/jaxrpc-api.jar"/>
<code-source path="${oracle.home}/webservices/lib/jaxb-api.jar"/>
<code-source path="${oracle.home}/webservices/lib/saaj-api.jar"/>
<code-source path="${oracle.home}/webservices/lib/jws-api.jar" if="java.specification.version == /1\.[5-6]/"/>
|
and comment out line which include jws-api.jar entry, like below
| Code Block | ||||
|---|---|---|---|---|
| ||||
<!-- <code-source path="${oracle.home}/webservices/lib/jws-api.jar" if="java.specification.version == /1\.[5-6]/"/> -->
|
...
- Edit deployment plan
- Edit
Configure class loadingin the deployment plan like described here - Uncheck
oracle.xmllibrary - Check
cxf.foundationlibrary - Uncheck
Search Local Classes First do not include
xercesImpl,xml-apis,xalanandgeronimo-ws-metadata_2.0_spec-1.1.1.jarinwar- those will be automatically loaded by by OC4J Shared Libraries class loader.Tip You can automate above steps by packaging You
warintoeararchive (even though) if it's onlywarand providingorion-application.xmlproprietary descriptor as described here. You could also provide proprietaryorion-web.xmlin YourwarinstrumentingSearch Local Classes Firstattribute described above. This step is described here.
...
I cannot get it to work still
...
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
...