Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of freeman.fang@gmail.com
 designates 209.85.160.41 as permitted sender)
From: Freeman Fang <freeman.fang@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1280)
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_89675493-B3BF-4549-B304-4FA941716AB3"
Subject: Re: Incompatible fault type is generated in the wsdl with RI command
Date: Thu, 18 Oct 2012 15:23:30 +0800
In-Reply-To: 
 <CALS1ypC-muKtbZz-9y=AsbDGAKe2OB5OTVom-M2v3x27gwMibQ@mail.gmail.com>
To: dev@cxf.apache.org
References: 
 <CALS1ypDPhRQRRb61nVttu7sMT3naRdTksZT3KP3TkkJGGAe7SQ@mail.gmail.com>
 <214D29BE-7406-4A5A-B124-F20B0A98E347@gmail.com>
 <CALS1ypC-muKtbZz-9y=AsbDGAKe2OB5OTVom-M2v3x27gwMibQ@mail.gmail.com>
Message-Id: <0BEEEAD6-BF00-41F3-B607-BB0E53C009DE@gmail.com>

--Apple-Mail=_89675493-B3BF-4549-B304-4FA941716AB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=GB2312

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

=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=
=AD
Freeman(Yue) Fang

Red Hat, Inc.=20
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 =CF=C2=CE=E72: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.
>=20
> 2012/10/18 Freeman Fang <freeman.fang@gmail.com>
>=20
>> Hi,
>>=20
>> 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,
>> =A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=A3=AD=
=A3=AD
>> Freeman(Yue) Fang
>>=20
>> 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
>>=20
>> On 2012-10-17, at =CF=C2=CE=E711:53, Ivan wrote:
>>=20
>>> Hi, with the exception class below , it only has a get*** method for =
the
>>> info property.
>>>=20
>>> @WebFault
>>> public TestException extends Exception {
>>>    private String message =3D null;
>>>=20
>>>   public TestException () {
>>>   }
>>>=20
>>>   public TestException (String message) {
>>>       this.message =3D message;
>>>   }
>>>=20
>>>   public String getInfo() {
>>>       return message;
>>>   }
>>>=20
>>> }
>>>=20
>>> With the RI wsgen command, the generated schema type is :
>>> RI:
>>> <xs:complexType name=3D"TestException">
>>>   <xs:sequence>
>>>     <xs:element name=3D"info" type=3D"xs:string" minOccurs=3D"0"/>
>>>     <xs:element name=3D"message" type=3D"xs:string" minOccurs=3D"0"/>
>>>   </xs:sequence>
>>> </xs:complexType>
>>> </xs:schema>
>>>=20
>>> If using CXF tool or on the CXF runtime, the generated schema type =
for
>> the
>>> exception is :
>>>=20
>>> <xs:element name=3D"TestException" type=3D"tns:TestException"/>
>>> <xs:complexType name=3D"TestException">
>>> <xs:sequence/>
>>> </xs:complexType>
>>>=20
>>> 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:
>>>=20
>>> 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.
>>>=20
>>> 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 ?
>>>=20
>>> --
>>> Ivan
>>=20
>>=20
>=20
>=20
> --=20
> Ivan


--Apple-Mail=_89675493-B3BF-4549-B304-4FA941716AB3--