Usually, while mapping the exception, one way is that we would expect a
faultbean is provided, with the getFaultInfo or WebFault. If not, the
things may depend. For this scenario, think CXF should generate a new JAXB
class to do the xml <---> object, The original exception instance will be
used to read the properties and set to the target jaxb classes. For the
client side, they do need to generate new classes for invocation, if they
would like to use the same classes, think they should specify the faultbean
and add required jaxb annotations.
If no objection, I would like to open a jira for this. ;-)
The generated jaxb/exception class will be something like
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "TestException", propOrder = {
"info",
"message"
})
public class TestException {
protected String info;
protected String message;
/**
* Gets the value of the info property.
*
* @return
* possible object is
* {@link String }
*
*/
public String getInfo() {
return info;
}
/**
* Sets the value of the info property.
*
* @param value
* allowed object is
* {@link String }
*
*/
public void setInfo(String value) {
this.info = value;
}
/**
* Gets the value of the message property.
*
* @return
* possible object is
* {@link String }
*
*/
public String getMessage() {
return message;
}
/**
* Sets the value of the message property.
*
* @param value
* allowed object is
* {@link String }
*
*/
public void setMessage(String value) {
this.message = value;
}
}
@WebFault(name = "TestException", targetNamespace = "
http://faultbean.test.com/";)
public class TestException_Exception
extends Exception
{
/**
* Java type that goes as soapenv:Fault detail element.
*
*/
private TestException faultInfo;
/**
*
* @param message
* @param faultInfo
*/
public TestException_Exception(String message, TestException faultInfo)
{
super(message);
this.faultInfo = faultInfo;
}
/**
*
* @param message
* @param faultInfo
* @param cause
*/
public TestException_Exception(String message, TestException faultInfo,
Throwable cause) {
super(message, cause);
this.faultInfo = faultInfo;
}
/**
*
* @return
* returns fault bean: com.test.faultbean.TestException
*/
public TestException getFaultInfo() {
return faultInfo;
}
}
2012/10/18 Daniel Kulp <dk...@apache.org>
>
> 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.
>
> Dan
>
>
>
> On Oct 17, 2012, at 11:53 AM, Ivan <xhh...@gmail.com> 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
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
Ivan
