I have no special talent. I'm only passionately curious - Albert Einstein
Apache CXF on WAS 7.0 Comment on Apache CXF on WAS 7.0 0

Apache CXF is an agile, open source web services framework that integrates out of the box with the Spring framework. This framework utilizes JAXB, and the new JAX-WS APIs, and does not require developers to use any proprietary APIs or annotations. CXF provides multiple transports - you can write a single service, and reuse it as a SOAP based web service, or a RESTful web service. The project, at the time of this writing, is very active, with new versions being released on a regular basis.

Developing CXF web services to run on the WebSphere Application Server presents some challenges. In January of 2010, an IBM developer released an article that was meant to address developing CXF web services for WAS 7.0. The article assumes, however, that developers will not be utilizing the WSDL generator provided by CXF when developing your web services. The recommended configuration does not work when attempting to utilize the WSDL generation portion of CXF. Even worse, the article was written with CXF 2.2.1 in mind, but the sample WAR file that can be downloaded clearly depends on CXF 2.1.3. The following configurations are required to run CXF services on Websphere Application Server 7.0. These configurations have been tested with CXF v2.2.5

  • You must have a commons-logging.properties file with the following properties, since CXF is using commons-logging-1.1:

  priority=1
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl

 

  • The MANIFEST.MF file in your web module must have the following property set to disable IBM's Web Services feature pack for your application:

  DisableIBMJAXWSEngine: true
 !IMPORTANT! DO NOT include the following property: UseWSFEP61ScanPolicy: true

 

 

  • When you build out your CXF service, if you copied all jar files from the apache-cxf-2.2.5\lib (from the distribution) into your WEB-INF/lib directory, you must make sure to remove the following jar files:
 * geronimo-activation_1.1_spec-1.0.2.jar
* geronimo-stax-api_1.0_spec-1.0.1.jar
* jaxb-api-2.1.jar
* jaxb-impl-2.1.12.jar
* saaj-api-1.3.jar
* saaj-impl-1.3.2.jar
* serializer-2.7.1.jar
* xalan-2.7.1.jar

If you don't remove those jar files, you will encounter classloader errors when attempting to run your application due to conflicts with IBMs jar files. The error will reveal itself in a stack trace like this, usually when requesting the generated WSDL for SOAP based Web Services:

 [2/1/10 11:49:22:908 CST] 00000027 servlet       E com.ibm.ws.webcontainer.servlet.ServletWrapper 
service SRVE0068E: Uncaught exception created in one of the service methods of the servlet WSCXFServlet
in application HRTSWebServicesEAR. Exception created : java.lang.VerifyError: JVMVRFY013 class loading

constraint violated; class=org/apache/xml/utils/UnImplNode, method=setUserData(Ljava/lang/String;
Ljava/lang/Object;Lorg/w3c/dom/UserDataHandler;)Ljava/lang/Object;, pc=0
at java.lang.J9VMInternals.verifyImpl(Native Method)

at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
at java.lang.J9VMInternals.verify(J9VMInternals.java:70)
at java.lang.J9VMInternals.verify(J9VMInternals.java:70)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)

at org.apache.xalan.transformer.TransformerIdentityImpl.<init>(TransformerIdentityImpl.java:88)
at org.apache.xalan.processor.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:823)
at org.apache.cxf.wsdl11.SchemaSerializer.writeXml(SchemaSerializer.java:57)

at org.apache.cxf.wsdl11.SchemaSerializer.marshall(SchemaSerializer.java:48)
at com.ibm.wsdl.xml.WSDLWriterImpl.printExtensibilityElements(Unknown Source)
at com.ibm.wsdl.xml.WSDLWriterImpl.printTypes(Unknown Source)

at com.ibm.wsdl.xml.WSDLWriterImpl.printDefinition(Unknown Source)
at com.ibm.wsdl.xml.WSDLWriterImpl.writeWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLWriterImpl.getDocument(Unknown Source)
at org.apache.cxf.transport.http.WSDLQueryHandler.writeResponse(WSDLQueryHandler.java:180)

at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:156)
at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)

at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)

at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1449)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:790)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:443)

at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:175)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3610)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:274)

at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:926)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1557)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:173)

at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:455)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:384)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:272)

at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)

at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)

at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:202)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:766)

at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:896)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1527)

 


Finally, when developing your web services using RAD or RSA (IBM's Eclipse based IDE), you will notice the following errors, that appear to be compile errors:

 

RSA errors that can be safely ignored

 

These errors can safely be ignored. If you follow IBM's suggestion and set the property UseWSFEP61ScanPolicy: true in your MANIFEST.MF file, your services WILL NOT RUN.


0 comments

Add a comment

Please provide your name, email address (won't be published) and a comment

About

David Malone is a Java developer residing in the Twin Cities area.  He has been developing enterprise applications since 2004.  This is his personal blog, as well as his design and development workspace.