cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "iris ding (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-4594) Incompatible fault type is generated in the wsdl if no setter method in Exception
Date Mon, 12 Nov 2012 02:26:12 GMT

    [ https://issues.apache.org/jira/browse/CXF-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495062#comment-13495062
] 

iris ding commented on CXF-4594:
--------------------------------

Hi Freeman,

Thanks a lot for your review and comments. 

I have a look for the problem again and found if we used wsdl2java to generate client club
classes, it works well. 
There will be issue if we use dynamic client which means we do not create any client stub
classes before hand. In such case, in JAXBEncoderDecoder.unmarshallException() method it will
fail because it will call the setter method to set the related valued for the Exception.
In such case, as client is only aware of the original Exception class so generating faultbean
on the fly by ourself does not work. I propose below solution for this problem, would you
please help to give your valuable comments for this?

In JAXBEncoderDecoder.unmarshallException() when there is no corresponding setter method:
try to see whether the Exception class has related filed defined and if so, set the value
of the field directly. If not, then just catch NoSuchMethodException and do nothing with the
it--just ignore it.

Thanks & Best Regards,

Iris Ding

                
> 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: JAXBContextInitializer.java.2.7Stream.patch, JAXBContextInitializer.java.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

Mime
View raw message