[
https://issues.apache.org/jira/browse/CXF-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486640#comment-13486640
]
Freeman Fang commented on CXF-4594:
-----------------------------------
Hi Iris,
Ah, I missed that part, sorry.
Take a closer look at this patch and more thoughts.
Your patch simply ignore the setter method, it might work for your case, which
will generate expected schema in wsdl.
However, if do unmarsell when received message, missing a setter will cause
problem.
Per jaxws spec 3.7, the related part is
For exceptions that do not match the pattern described in section 2.5, JAX-WS
maps those exceptions to Java beans and then uses those Java beans as input to
the JAXB mapping. The following algorithm is used to map non-matching exception
classes to the corresponding Java beans for use with JAXB:
1. In the absence of customizations, the name of the bean is the same as the
name of the Exception suffixed with “Bean”.
2. In the absence of customizations, the package of the bean is a generated
jaxws subpackage of the SEI package. E.g. if the SEI package is
com.example.stockquote then the package of the bean would be
com.example.stockquote.jaxws.
3. For each getter in the exception and its superclasses, a property of the
same type and name is added to the bean. The getCause, getLocalizedMessage and
getStackTrace getters from java- .lang.Throwable and the getClass getter from
java.lang.Object are excluded from the list of getters to be mapped.
4. The bean is annotated with a JAXB @XmlType annotation. If the exception
class has a @XmlType annotation, then it is used for the fault bean’s @XmlType
annotation. Otherwise, the fault bean’s @XmlType annotation is computed with
name property set to the name of the exception and the namespace property set
to the target namespace of the corresponding portType. Additionally, the
@XmlType annotation has a propOrder property whose value is an array containing
the names of all the properties of the exception class that were mapped in the
previous bullet point, sorted lexico- graphically according to the Unicode
value of each of their characters (i.e. using the same algorithm that the int
java.lang.String.compareTo(String) method uses).
5. The bean is annotated with a JAXB @XmlRootElement annotation whose name
property is set, in the absence of customizations, to the name of the exception.
So IMO Per the spec, need generate this java bean on the fly which is input to
the JAXB mapping, this java bean will gather getters from customer exception
and add setters accordingly, and this java bean is used for JAXB to do
marshal/unmarsel.
Currently CXF in code first way, just use the custom exception as input to the
JAXB maping, not generate the java bean on the fly, that's why setters can't be
ignored. So if you wanna follow the JAXWS spec 3.7 exactly, you must create
that java bean on the fly yourself.
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
> Fix For: 2.7.0
>
> 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
