You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by apsolapso <sl...@raccoonslair.com> on 2009/01/21 15:39:16 UTC
Reflection problems with Fault hierarchy
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.
Re: Reflection problems with Fault hierarchy
Posted by Daniel Kulp <dk...@apache.org>.
Testing a fix for this now. It will be in 2.1.4.
Dan
On Wednesday 21 January 2009 9:59:22 am apsolapso wrote:
> I might add that CXF breaks down at:
> org.apache.cxf.interceptor.ClientFaultConverter.processFaultDetail(ClientFa
>ultConverter.java:154)
>
> apsolapso wrote:
> > 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.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Reflection problems with Fault hierarchy
Posted by apsolapso <sl...@raccoonslair.com>.
I might add that CXF breaks down at:
org.apache.cxf.interceptor.ClientFaultConverter.processFaultDetail(ClientFaultConverter.java:154)
apsolapso wrote:
>
> 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-tp21584356p21584827.html
Sent from the cxf-dev mailing list archive at Nabble.com.