cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Incompatible fault type is generated in the wsdl with RI command
Date Wed, 17 Oct 2012 19:11:46 GMT

Interesting….   I would have expected CXF to generate the "message" element at least.  
Although I guess that is redundant with the fault:message that would already be there.

The main issue I have with not checking for setters is that we'd have no way to use the fault
on the client side.  Since CXF (and JAX-WS) generally tries to make the same set of classes
usable on the server and client side, that would suck.    Thus, we could generate the two
elements, on the server side we could use that to generate the fault message, but when the
client receives the message, we would not be able to map the "info" and "message" elements
into anything that could be put into the exception that is thrown back to the client.  Thus,
that information would be discarded.   That bothers me.


On Oct 17, 2012, at 11:53 AM, Ivan <> wrote:

> Hi, with the exception class below , it only has a get*** method for the
> info property.
> @WebFault
> public TestException extends Exception {
>     private String message = null;
>    public TestException () {
>    }
>    public TestException (String message) {
>        this.message = message;
>    }
>    public String getInfo() {
>        return message;
>    }
> }
> With the RI wsgen command, the generated schema type is :
> RI:
> <xs:complexType name="TestException">
>    <xs:sequence>
>      <xs:element name="info" type="xs:string" minOccurs="0"/>
>      <xs:element name="message" type="xs:string" minOccurs="0"/>
>    </xs:sequence>
>  </xs:complexType>
> </xs:schema>
> If using CXF tool or on the CXF runtime, the generated schema type for the
> exception is :
> <xs:element name="TestException" type="tns:TestException"/>
> <xs:complexType name="TestException">
> <xs:sequence/>
> </xs:complexType>
> With the JaxWS spec, 3.7 Service Specific Exception, considering that no
> getFaultInfo or faultBean in WebFault annotation is provided, the
> special algorithm will be used to map the exception to jaxb bean, one of
> the steps write below:
> For each getter in the exception and its superclasses, a property of the
> same type and name is added to
> the bean. All the getter methods except
> getMessagefromjava.lang.Throwabletype hierarchy
> are excluded from the list of getters to be mapped.
> Seems that only getter method is required, with the current codes in static
> boolean JAXBContextInitializer.isMethodAccepted, it will check whether the
> setter exists. I am thinking that this is not required for this scenario,
> as we only need to read the information from the user exception. Thoughts ?
> -- 
> Ivan

Daniel Kulp -
Talend Community Coder -

View raw message