Page History

...

• Run "jar cvf ..." command to create the ear and then deploy it. Alternatively, this blog entry provides a Mavenized method of building the EAR.

Websphere

For WebSphere Versions < 6.1.0.29

Adding Currently, I've only found one way to make cxf work with websphere: adding jars to the 'endorsed' folder . (*Note: this has been validated against Websphere6.1.0.0, 6.1.0.19, and 6.1.0.27 *)

No Web Services Feature Pack for WebSphere installed

...

appears to be the main solution:

No Web Services Feature Pack for WebSphere installed

put jar in the endorsed folder

• put the wsdl4j-1.6.1.jar in the $WebSphere_HOME/java/jre/lib/endorsed folder.
• In the WebSphere console, find the specific enterprise application, click the "Class loading and update detection".
  • Mark the "Classes loaded with application class loader first" selected.
  • Mark the "Class loader for each war file in application" selected.

...

Add your own class loader

If you put your wsdl4j-1.6.1 jar in $WAS_HOME/java/jre/lib/endorsed, all your applications will depend on your version of wsdl4j. Another solution is to create a new class loader in your server which loads before parent class loader, create a shared library with your version of wsdl4j, and add this shared library to your new class loader. This version of wsdl4j will only be available for your specific server and not affect applications running in other servers.

...

Create a shared library with the following jars:
jsr173_api-1.0.jar
jaxp-ri-1.4.2.jar
saaj-impl-1.3.2.jar
wsdl4j-1.6.2.jar

Create a new parent-first classloader and have it reference the shared library you just created. Restart everything and it should work.

Web Services Feature Pack for WebSphere Installed

Things are way more complicated if the Web Services Feature Pack for WebSphere is installed. With this feature pack installed, it is impossible to deploy an application using CXF, because the WebSphere Web Services engine starts parsing the JAX-WS annotations of the services and tries to deploy the services.

Up to fixpack 27 (6.1.0.27) there was no possibility to disable the WebSphere Web Services engine.

In October 2009, IBM reacted to the problem and released the following fix:

  PK96989: ENABLE USE OF THIRD PARTY JAX-WS WEB SERVICES ENGINE IN WEBSPHERE

This fix requires at least fixpack 27 (6.1.0.27). It allows to disable the WebSphere Web Services
engine for the whole JVM by setting the JVM property

  com.ibm.websphere.webservices.DisableIBMJAXWSEngine=true

or to disable the engine just for a specific module by adding

  DisableIBMJAXWSEngine: true

to WAR/META-INF/MANIFEST.MF.

According to IBM, this fix shall be included into fixpack 29.

For details, please see http://www-01.ibm.com/support/docview.wss?rs=180&amp;uid=swg1PK96989^{Image Removed}

For WebSphere 6.1.0.29+, V7 and V8

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

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.

To disable for the whole JVM, set the JVM property

com.ibm.websphere.webservices.DisableIBMJAXWSEngine=true

or to disable the engine just for a specific module by adding

DisableIBMJAXWSEngine: true

to WAR/META-INF/MANIFEST.MF.The WebSphere team has also added instructions for using third party JAX-WS applications to their tech articles: http://www.ibm.com/developerworks/websphere/library/techarticles/1001_thaker/1001_thaker.html^{Image Removed}

Glassfish

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:

...