[
https://issues.apache.org/jira/browse/CXF-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497008#comment-13497008
]
Freeman Fang commented on CXF-4594:
-----------------------------------
Hi Iris,
Good catch!
But it's not bug in com.sun.xml.bind.v2.runtime.unmarshaller, it's the fact
that client and server in WSAFromJavaTest.testAddNumbersFault() are using
different Exception.
On client side, it use
org.apache.cxf.systest.ws.addr_fromjava.client.AddNumbersException, which is
generated from wsdl
{code}
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "AddNumbersException")
@Generated(value = "com.sun.tools.xjc.Driver", date =
"2012-11-14T05:45:44+08:00", comments = "JAXB RI v2.2.6")
public class AddNumbersException {
}
{code}
but on server side, it use
org.apache.cxf.systest.ws.addr_fromjava.server.AddNumbersException, which is
{code}
public class AddNumbersException extends Exception {
private static final long serialVersionUID = 4629689348515005826L;
String detail;
public AddNumbersException(String message, String detail) {
super(message);
this.detail = detail;
}
public String getDetail() {
return detail;
}
}
{code}
So on client side, it won't expect a detail element in AddNumbersException
during unmarshalling.
We can't see this issue without your patch because before the "detail" property
of org.apache.cxf.systest.ws.addr_fromjava.server.AddNumbersException can't get
marshalled at all on server side.
Yeah, it's your patch reveal this issue. And I'd say change
WSAFromJavaTest.testAddNumbersFault() to make client and server see same
service model.
Thanks
Freeman
> Incompatible fault type is generated in the wsdl if no setter method in
> Exception
> ---------------------------------------------------------------------------------
>
> Key: CXF-4594
> URL: https://issues.apache.org/jira/browse/CXF-4594
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
> Affects Versions: 2.7.0
> Reporter: iris ding
> Labels: patch
> Attachments: CXF-4594.patch, CXF-4594-testnew.patch,
> CXF-4594-test.patch
>
>
> 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.
> The patch will return true is the getter method has no corresponding setter
> method to let CXF comply with the jax-ws 2.2 spec:
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
