Is the value you are setting it to a QName? The SOAP 1.1 spec requires
it to be a QName and CXF may reject setting the value if it is not.
Azazelus wrote:
Is there any other way I could change faultCode according to the needs?
I am searching through all internet resources back and forth but
existing way to do this? Thank you.
Fred
Frederick N. Brier wrote:
I thought it was yet another problem with the web service not
declaring a SOAP fault on an operation, but now I am not sure. The
SOAP operation listed a Fault that was of a base type of the fault
that was thrown. When
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
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
Benson Margulies wrote:
On Thu, 2008-01-24 at 13:05 -0500, 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
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.
The WSDL2Java CXF generated web service is not sending a SOAP header.
Perhaps it is because it is an implicit header? I tried the -exsh, but
that did not cause the header to be generated. The doc seems to
indicate that it causes the header to be processed if it is not there,
implying that
