[
https://issues.apache.org/jira/browse/CXF-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13496198#comment-13496198
]
Freeman Fang edited comment on CXF-4594 at 11/13/12 2:19 PM:
-------------------------------------------------------------
Hi Iris,
I'm a little bit confused, I just copy AddNumbersException as your
TestException here which you described in this issue
{code}
@WebFault
public TestException extends Exception {
private String message = null;
public TestException () {
}
public TestException (String message) { this.message = message; }
public String getInfo() { return message; }
}
{code}
It should be exactly what you want, then please tell me what's the exception in
your mind with this issue, show me the code please.
I hope this issue can really resolve the code first customer exception
issue(some properties only have get but no set) during runtime, not only
generate the wsdl you want. Moreover, we really can't apply a patch that can
generate the a desired wsdl but the runtime actually doesn't work at all, that
means the interface description and behavior isn't consistent.
If you are more care about the wsdl, you can simply add
@XmlAccessorType(XmlAccessType.FIELD)
for your exception class, actually this can also resolve the property marshall
problem.
Freeman
was (Author: ffang):
Hi Iris,
I'm a little bit confused, I just copy AddNumbersException as your
TestException here which you described in this issue
{code}
@WebFault
public TestException extends Exception {
private String message = null;
public TestException () {
}
public TestException (String message) { this.message = message; }
public String getInfo() { return message; }
}
{code}
It should be exactly what you want, then please tell me what's the exception
you wanna handle with this issue, show me the code please.
I hope this issue can really resolve the code first customer exception issue
during runtime, not only generate the wsdl you want.
If you are more care about the wsdl, you can simply add
@XmlAccessorType(XmlAccessType.FIELD)
for your exception class, actually this can also resolve the property marshall
problem.
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-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
