I have noticed CXF has a problem with inheritance in the wsdl.
We have a wsdl:operation that returns a Fault, let's call it MyWSFault,
according to the publishd WSDL:
// Element declaration
<xsd:element name="myWSFault" type="tns:MyWSFault" />
// Operation declaration
<wsdl:operation name="myService">
<wsdl:input name="myServiceRequest" message="tns:myServiceRequest"/>
<wsdl:output name="myServiceResponse" message="tns:myServiceResponse"/>
<wsdl:fault name="MyWSFault" message="tns:myWSFault"/>
</wsdl:operation>
Now, in the WSDL a number of extensions/implementations of the fault are
defined like this:
<xsd:complexType abstract="true" name="MyWSFault">
<xsd:sequence>
// Stuff
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MySubFault">
<xsd:complexContent>
<xsd:extension base="tns:MyWSFault" />
</xsd:complexContent>
</xsd:complexType>
// More subtypes
Now, if a subfault (i.e. MySubFault) is returned from the web service we get
an "exception while creating exception" in CXF. It seems the problem is that
CXF uses reflection to instantiate the Java exception, and that this
functionality looks for a constructor taking a "MyWSFault" object, though
what it actually has is a "MySubFault" object (which extends MyWSFault).
The generated code looks like this:
private MyWSFault exception;
public MyException(String message, MyWSFault mwsf) {
super(message);
exception = mwsf;
}
If we hack the generated classes and adds the following constructor
everything starts working again:
public MyException(String message, MySubFault mwsf) {
super(message);
exception = mwsf;
}
Shouldn't this work without the manually added constructor as well? Is this
an oversight in CXF or en error in the reflection code? Seems someone may
have used <T> where they ought to have used <? extends T>...
Cheers!
/Robert.
--
View this message in context:
http://www.nabble.com/Reflection-problems-with-Fault-hierarchy-tp21584356p21584356.html
Sent from the cxf-dev mailing list archive at Nabble.com.
