cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: Incompatible fault type is generated in the wsdl with RI command
Date Thu, 18 Oct 2012 07:23:30 GMT
Yeah, I must admit CXF does't exactly follow the JAXWS spec 3.7, that's could be issues when
use code-first way with exception.
Could you please create a jira to track this issue, and patch are welcomed, as always.
Thanks
Freeman

-------------
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042

On 2012-10-18, at 下午2:24, Ivan wrote:

> Yes, with current CXF generation codes, I could see only in/out jaxb
> classes are generated in WrapperClassGenerator (if I did not miss anything
> here ;-))
> But, think that it is required to generate the fault jaxb class per the
> description in 3.7 Service Specific Exception, XmlAccessType.FIELD will not
> workaroud all the issues, at least for the message property in the
> Exception hierarchy.
> 
> 2012/10/18 Freeman Fang <freeman.fang@gmail.com>
> 
>> Hi,
>> 
>> If there's no FaultBean in @webFault and no getFaultInfo method in
>> TestException class, currently CXF will put the exception class itself as
>> the FaultBean, so you need ensure field in TestException could be
>> marshaled/unmarshalled correctly by jaxb, so just add
>> @XmlAccessorType(XmlAccessType.FIELD) in TestException can do the trick,
>> -------------
>> Freeman(Yue) Fang
>> 
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Web: http://fusesource.com | http://www.redhat.com/
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> http://blog.sina.com.cn/u/1473905042
>> weibo: http://weibo.com/u/1473905042
>> 
>> On 2012-10-17, at 下午11:53, 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
>> 
>> 
> 
> 
> -- 
> Ivan


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message