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 6

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.


6 comments

Dave - January 14, 2011

@Sanjeeva - thanks for letting me know.  Were you running Java 1.6?  I believe all of the code I tested was running Java 1.5.

 

Sanjeeva - December 12, 2010

with was 7.0.07 i was getting following exection, by remonving jaxb-impl-2.1.13.jar from workspace  resolved issue.

java.lang.ClassCastException: com.XXX.XXXX.XXXX.dto.soap.SoapParam$JaxbAccessorM_getKey_setKey_java_lang_String incompatible with com.sun.xml.bind.v2.runtime.reflect.Accessor

at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190)
    at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:135)
    at com.sun.xml.bind.v2.runtime.reflect.Accessor$GetterSetterReflection.optimize(Accessor.java:392)
    at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:233)
    at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:173)
    at com.sun.xml.bind.v2.runtime.property.AttributeProperty.<init>(AttributeProperty.java:87)
    at com.sun.xml.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:104)
    at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.<init>(ClassBeanInfoImpl.java:179)
    at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:515)
    at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:534)
    at com.sun.xml.bind.v2.runtime.ArrayBeanInfoImpl.<init>(ArrayBeanInfoImpl.java:74)
    at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:524)
    at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:324)
    at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1140)
    at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:154)
    at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:121)

voji - October 02, 2010

Please submit a working example project. I try this and always getting error:

Caused by: java.lang.ClassCastException: my.project.services.Request$JaxbAccessorM_getApplicationName_setApplicationName_java_lang_String incompatible with com.sun.xml.bind.v2.runtime.reflect.Accessor
    at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190)
    at com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:135)
    at com.sun.xml.bind.v2.runtime.reflect.Accessor$GetterSetterReflection.optimize(Accessor.java:392)
    at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.<init>(SingleElementLeafProperty.java:82)

Hayo Schmidt - September 30, 2010

We got the whole thing running _without_ changing the classloader order.

 

We also needed a Shared Library:

bcel-5.2.jar
serializer-2.7.1.jar
wsdl4j-1.6.2.jar
xalan-2.7.1.jar
xercesImpl-2.8.1.jar
XmlSchema-1.4.5.jar
saaj-impl-1.3.4.jar
jaxb-impl-2.1.13.jar
jaxp-ri-1.4.2.jar

 

The Shared Libraray must be assigned to the application.

 

The following JVM Custom properties are set:

JAXP

javax.xml.transform.TransformerFactory org.apache.xalan.processor.TransformerFactoryImpl
javax.xml.xpath.XPathFactory org.apache.xpath.jaxp.XPathFactoryImpl
javax.xml.parsers.SAXParserFactory org.apache.xerces.jaxp.SAXParserFactoryImpl
javax.xml.parsers.DocumentBuilderFactory org.apache.xerces.jaxp.DocumentBuilderFactoryImpl

 

StAX

 

javax.xml.stream.XMLOutputFactory com.sun.xml.internal.stream.XMLOutputFactoryImpl

 

Additionally we set DisableIBMJAXWSEngine: true in META-INF/MANIFEST.MF, because it is documented to do so. (It did run without on my machine)

 

The functionality we need runs fine. Whether everything works: try out yourself.

 

Remarks:

 

I assume that the shared libraries could be as well provided as utility Jars in an EAR file. But i did not try this out.

 

The properties could be set alternatively in META-INF/services/ and be provided in a shared lib or utility jar. Please see API documentation. (Did not try this myself either)

Hayo Schmidt - September 30, 2010

I forgot...

Server version was IBM WebSphere Application Server v7.0.0.9

Dave - October 02, 2010

@Hayo - You don't need to take these steps to work with WAS 7.0 and above.  Thanks for your comments, though.  @Voji - When I wrote this, all of the example code worked on WAS 6.1.0.29 with JDK 5.  Feel free to contact me for more specifics.

Comments are currently disabled

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.