You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Frederick N. Brier" <fb...@reflexsecurity.com> on 2008/01/28 19:25:36 UTC

Re: ClientFaultConverter and schema extension {Possibly Forged}

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
>