Andreas,

Thanks for your reply. Initially I thought to be a SAAJ version mismatch,
but this issue seems to be related specifically to cxf 2.2.6. When I drop in
cxf-2.0-incubator instead of cxf-2.2.6 jar, I do not get this error - 

java.lang.NoSuchMethodError:
javax/xml/soap/SOAPFault.setFaultCode(Ljavax/xml/namespace/QName;)V

So I am at loss why it works with one version and not with the other. 

thanks
Sid



 

Andreas Veithen-2 wrote:
> 
> Sid,
> 
> Why do you think that the problem comes from the QName class not being
> found? The java.lang.NoSuchMethodError indicates that the problem is
> with a SAAJ version mismatch.
> 
> Andreas
> 
> On Wed, Mar 3, 2010 at 00:10, PrSd <[email protected]> wrote:
>>
>>
>> The WAS server library is part of the "Order and Export" setup inside RSA
>> which has the webapp library (all CXF/Spring/SAML jars) ahead of WAS
>> runtime
>> (j2ee jar). SAAJ1.2 jars are endorsed in the IBM's JDK endorsed
>> directory.
>>
>> However when I am running the SOAPclient from within RSA, it keeps
>> throwing
>> this error as if it cannot see the QName (embedded in the WAS j2ee jar)
>> on
>> the classpath. It appears the SAAJ 1.2 libraries cannot see the WAS
>> server
>> j2ee jar.
>>
>> What am I missing
>>
>> thanks
>> Sid
>>
>>
>>
>>
>>
>>
>> dkulp wrote:
>>>
>>> On Tue March 2 2010 2:14:44 pm PrSd wrote:
>>>> 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?
>>>
>>> You shouldn't need a jar with it in as it's part of Java 5.
>>>
>>> Dan
>>>
>>>
>>>>
>>>> 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(SAAJInI
>>>> >> nterceptor.java:154)
>>>> >>
>>>> >>     at
>>>> >>
>>>> >>
>>>> org.apache.cxf.jaxws.handler.soap.SOAPMessageContextImpl.getMessage(SOAP
>>>> >> MessageContextImpl.java:78)
>>>> >>
>>>> >>     at
>>>> >>
>>>> >>
>>>> org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.createProtocolM
>>>> >> essageContext(SOAPHandlerInterceptor.java:236)
>>>> >>
>>>> >>     at
>>>> >>
>>>> >>
>>>> org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessageIn
>>>> >> ternal(SOAPHandlerInterceptor.java:144)
>>>> >>
>>>> >>     at
>>>> >>
>>>> >>
>>>> org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(S
>>>> >> OAPHandlerInterceptor.java:119)
>>>> >>
>>>> >>     at
>>>> >>
>>>> >>
>>>> org.apache.cxf.jaxws.handler.soap.SOAPHandlerInterceptor.handleMessage(S
>>>> >> OAPHandlerInterceptor.java:69)
>>>> >>
>>>> >>     at
>>>> >>
>>>> >>
>>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
>>>> >> hain.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
>>>
>>> --
>>> Daniel Kulp
>>> [email protected]
>>> http://www.dankulp.com/blog
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/CXF-SAAJ-Version-compatibility-with-WAS6.1-tp27757073p27762473.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
> 
> 

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

Reply via email to