cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From PrSd <sidharthapr...@yahoo.com>
Subject Re: CXF/SAAJ Version compatibility with WAS6.1
Date Tue, 02 Mar 2010 19:14:44 GMT

Ok..I replaced stax-api-1.0.1.jar with woodstox - three that came with the
distribution - woodstox-core-asl-4.0.7.jar, woodstox-core-lgpl-4.0.7.jar and
stax2-api-3.0.1.jar. However none of them is packaged with a QName class. 

So not sure what is the right approach still. Any takers?

thanks
Sid





PrSd wrote:
> 
> Interestingly when I drop in "stax-api-1.0.1.jar" the error goes away.
> This is because the jar contains the javax.xml.namespace.QName. However
> this appears to be a jar that was used in XFire/CXF Incubator
> implementation and should not be used in the newer CXF distributions(not
> shipped anyhow). Besides it may be using a DOM1 level specification for
> XML Streaming/Parsing. 
>  
> So I guess the obvious question is what is the replacement for
> stax-api-1.0.1 for CXF 2.2.6 or is there one? I do know we have the SUN
> JAXP - jaxp-ri-1.4.1.jar that has the QName class, but OpenSAML Validation
> chokes complaining I should be using the Xerces, Xalan, XML Apis provided
> by OpenSAML. So I cannot use the jaxp-r1-1.4.1 jar distribution for
> resolving the QName. 
> 
> thanks
> Sid
> 
> 
> 
> PrSd wrote:
>> 
>> Server Environment: 
>> WAS 6.1 (only endorses SAAJ1.2) , CXF 2.2.6 (uses SAAJ1.3), Spring 2.5.6
>> and Open SAML 2.3
>> 
>> When running the SOAPClient from within RAD 7.0 I am 
>> 
>> Getting a 
>> 
>> Exception in thread "main" java.lang.NoSuchMethodError:
>> javax/xml/soap/SOAPFault.setFaultCode(Ljavax/xml/namespace/QName;)V
>>     at
>> org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:154)
>>     at
>> org.apache.cxf.jaxws.handler.soap.SOAPMessageContextImpl.getMessage(SOAPMessageContextImpl.java:78)
>>     at
>> org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.createProtocolMessageContext(SOAPHandlerInterceptor.java:236)
>>     at
>> org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessageInternal(SOAPHandlerInterceptor.java:144)
>>     at
>> org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:119)
>>     at
>> org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(SOAPHandlerInterceptor.java:69)
>>     at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
>>     at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:672)
>> 
>> This appears to be a SAAJ Version mismatch. So here is my setup.
>> 
>> However even if I endorse SAAJ1.3.2 on WAS, Websphere 6.1 does not
>> support and gets confused and never recognizes that library. (although
>> WAS 7.0 supports SAAJ1.3.2). My WS client is being run from inside the
>> Rational (Eclipse) IDE. On the server, I have endorsed using the SAAJ1.2
>> libraries on the WAS server which WAS recognizes.
>> 
>> So to be consistent on the client side I try to endorse the same SAAJ1.2
>> jars, however CXF 2.2.6 only uses SAAJ1.3 and thus throws the above
>> exception.
>> 
>> Please correct if my above assumption is misplaced. So my question is
>> what version of CXF uses a SAAJ1.2 implementation so that it is
>> compatible with WAS6.1. Also since I am using Open SAML I would like to
>> make sure that I am using the SAAJ libraries that is using a DOM2 parser
>> for DOM building of the SOAP messages.
>> 
>> thanks a much in advance
>> Sid
>> 
> 
> 

-- 
View this message in context: http://old.nabble.com/CXF-SAAJ-Version-compatibility-with-WAS6.1-tp27757073p27759939.html
Sent from the cxf-user mailing list archive at Nabble.com.


Mime
View raw message