Daniel,
Thank you much. I did write a javax.xml.ws.handler.soap.SOAPHandler and
fixed the issue in the handleFault() method. That got me past that
issue, but I may have run into something else which I will post in a second.
Fred
Daniel Kulp wrote:
You should be able to write an interceptor the would sit before any of
the SAAJ or other soap interceptors on the fault in chain only that
would just DOM parse the thing, manipulate the DOM, and then reset the
message content to the contents of the new DOM. Kind of sucky.
A more "interesting" approach might be to wrapper the XMLStreamReader
with a new XMLStreamReader that, if the current element name
is "faultcode", would just map the call to get the characters to a
proper SOAP 1.1 qualified version.
Dan
On Thursday 24 January 2008, Frederick N. Brier wrote:
I reread my own posting and realized that the problem is not in the
detail element, but in the <faultcode> element which contains an
arbitrary string, "ServerFaultCode", not a QName. The exception says:
"No NamespaceURI, SOAP requires faultcode content to be a QName"
I believe the faultcode element and QName requirement was introduced
with SOAP 1.1. Can CXF be forced to validate using SOAP 1.0? If so,
how? What are the ramifications? I checked the schemas specified in
the WSDL document and they appear to be SOAP 1.0. Why didn't CXF
automatically use same SOAP 1.0 schemas as were defined in the WSDL
document?
The VMWare/Axis web service appears to be placing the qualified fault
element in the contents of the <detail> element. How do I get around
this? Is there a way (interceptor?) to fix the XML prior to being
parsed? This would involve moving and translating the <detail>
element contents to a QName stored in the contents of the <faultcode>
element. If I can force CXF to SOAP 1.0, will it still know to
generate an exception using the QName in the <detail> element? Or is
where I would use a custom Interceptor and specify it in the
<inFaultInterceptors> of the CXF Spring configuration. Has anyone
already written an Axis to CXF fault translator?
Thank you for your help.
Thank you.
Fred
Frederick N. Brier wrote:
I am writing a client to a VMWare management web service. In
working with the API, I made a mistake and a SOAP fault was thrown.
That is not the problem. Instead of an WSDL generated exception
class being thrown, I got what appears to be a validation error
during parsing of the SOAP fault. Below is the SOAP fault message
that caused the exception and below that is the stack trace. SOAP
fault message:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<soapenv:Body>
<soapenv:Fault>
<faultcode>ServerFaultCode</faultcode>
<faultstring>specSet</faultstring>
<detail>
<InvalidRequestFault xmlns="urn:vim2"
xsi:type="InvalidRequest"/>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
Here is the stack trace:
Jan 23, 2008 4:56:09 PM
com.sun.xml.messaging.saaj.soap.impl.FaultImpl setFaultCode
SEVERE: SAAJ0140: No NamespaceURI, SOAP requires faultcode content
to be a QName
java.lang.reflect.UndeclaredThrowableException
at $Proxy32.retrieveProperties(Unknown Source)
at
com.reflexsecurity.vmware.SampleClient.retrieveProperties(SampleClie
nt.java:216)
at
com.reflexsecurity.vmware.SampleClient.main(SampleClient.java:82) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl
.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce
ssorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: No
NamespaceURI, SOAP requires faultcode content to be a QName at
com.sun.xml.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImp
l.java:101)
at
com.sun.xml.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImp
l.java:138)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:1
55) ... 8 more
Failed to retrieve properties.
2008-01-23 16:56:09,872 ERROR main SampleClient.main:96] Failed to
retrieve properties
java.lang.reflect.UndeclaredThrowableException
at $Proxy32.retrieveProperties(Unknown Source)
at
com.reflexsecurity.vmware.SampleClient.retrieveProperties(SampleClie
nt.java:216)
at
com.reflexsecurity.vmware.SampleClient.main(SampleClient.java:82) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl
.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce
ssorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: No
NamespaceURI, SOAP requires faultcode content to be a QName at
com.sun.xml.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImp
l.java:101)
at
com.sun.xml.messaging.saaj.soap.impl.FaultImpl.setFaultCode(FaultImp
l.java:138)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:1
55) ... 8 more
Process finished with exit code 0
