I would still love a collaborating statement saying I am interpreting
this correctly. I vaguely remember having this question 5+ years ago,
but cannot remember what I decided. The spec
[http://www.w3.org/TR/wsdl], in section 2.4.5, states:
"Each fault element must be named to allow a binding to specify the
concrete format of the fault message. The name of the fault element
is unique within the set of faults defined for the operation."
This would seem to say that polymorphism/inheritance of fault elements
is not supported. A concrete element structure must be named for each
possible exception/SOAP fault that might be thrown/returned. Specifying
the base "element" does not allow "derived" faults to be used unless
explicitly listed in the operation. This means CXF is correct and the
VMWare API is not.
As an aside, it would be nice if the expected Java exception were thrown
in spite of the incorrect WSDL. I could write a replacement
ClientFaultConverter or an additional InFaultInterceptor. I was trying
to figure out how to get the exception's Java class from the QName. Is
there an easy JaxB helper method or map that will give me that? Or is
there another 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 ClientFaultConverter iterated over the
operation's listed faults it did not match. So it threw a generic
SoapFault. So what does SOAP 1.1 standard say? Should a WSDL list
each fault even if they are extensions of some base element? Or
should listing a base element as the fault be acceptable, inheriting
not just form, but function? If the latter, then ClientFaultConverter
would need to be amended in some fashion. Thank you for any insight
on this.
Fred
