Details
Description
WSDL Fragment –
----------------------------
<complexType name="InvalidRequest">
<complexContent>
<extension base="vim3:RuntimeFault">
<sequence>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="RuntimeFault">
<complexContent>
<extension base="vim3:MethodFault">
<sequence>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RuntimeFaultFault" type="vim3:RuntimeFault"/>
<message name="RuntimeFaultFaultMsg">
<part name="fault" element="vim3:RuntimeFaultFault" />
</message>
<portType name="VimPortType">
<operation name="DestroyPropertyFilter">
<input message="vim3:DestroyPropertyFilterRequestMsg" />
<output message="vim3:DestroyPropertyFilterResponseMsg" />
<fault name="RuntimeFault" message="vim3:RuntimeFaultFaultMsg"/>
</operation>
--------------------------------
Note that InvalidRequst is an extension of complex type RuntimeFault which is used as a type of fault. WSGen generates "RuntimeFaultFaultMsg" exception class but it does not generate a class for InvalidFault (and obviously does not reflect the inheritance relationship between RuntimeFault and InvalidRequest).
WSGen and core does not take into account that schema may contain polymorphic types that are used in faults.
End result is that when SOAP fault is received with detail field containing InvalidRequest, it is turned into some generic XFire fault.
This seems pretty broken since inheritance is pretty important in handling / categorizing exceptions in Java.