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
