You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Richard Opalka <ro...@redhat.com> on 2012/11/30 14:53:11 UTC
Exceptions inheritance JAXB de/serialization issue
Hi CXF folks,
Below is copy/paste from JAXWS 2.2 spec, Section 3.7 - Service Specific
Exception:
---
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.
---
I'm wondering why CXF isn't using generated 'exception' beans for JAXB
de/serialization & WSDL generation
but instead operate directly on top of exception objects? I know CXF is
passing TCK, but isn't it violating JAXWS spec.?
Most probably TCK tests doesn't cover this issue :(
Cheers,
--
Richard Opalka
Principal Software Engineer
JBoss, by Red Hat
Cell: +420 731 186 942
Re: Exceptions inheritance JAXB de/serialization issue
Posted by Richard Opalka <ro...@redhat.com>.
Just FYI another related discussion:
http://mail-archives.apache.org/mod_mbox/cxf-users/200903.mbox/%3C200903061306.02909.dkulp@apache.org%3E
My conclusion is this is JAXWS spec. problem.
I found nice blog what users can do in this particular use case:
http://io.typepad.com/eben_hewitt_on_java/2009/07/using-soap-faults-and-exceptions-in-java-jaxws-web-services.html
Cheers,
Rio
PS: I'm closing CXF-4600 as won't fix.
On 12/03/2012 04:15 PM, Richard Opalka wrote:
> Hello CXF folks,
>
> after googling, reading the specs. & blogs whole day
> I have few additional findings.
> I was playing little bith with JAXWS-RI today and
> I see exception inheritance is broken there as well.
> JAXWS RI according to JAXWS spec. requirement
> generates exception 'beans' for all checked exceptions
> that are not @WebFault annotated.
> What I discovered is if I have the following
> exceptions hierarchy:
>
> SubException extends SuperException
> * String a * String b
>
> The JAXWS RI translates this to:
>
> SubExceptionBean SuperExceptionBean
> * String a * String b
> * String b
>
> and ...
> Exactly, you're not blind! The inheritance
> hierarchy is broken/eliminated in generated beans.
> Another interesting issue I identified in JAXWS RI
> is it ignores @XmlTransient on exceptions.
> This said when exception 'beans' are generated for
> checked exceptions not annotated with @WebFault,
> the @XmlType and other similar JAXB sensitive annotations
> are propagated from original exceptions to generated exception beans.
> But @XmlTransient not. (http://java.net/jira/browse/JAXB-136)
> OK, this was about how JAXWS RI works.
> IMHO JAXWS spec. is very secret and silent in this exceptions area.
> This probably resulted to fact Apache CXF implements it differently
> than JAXWS RI does. I mean Apache CXF JAXB databinding is not using
> generated exception 'beans' but rather operates on top of exception
> objects instead.
> I was trying to fix CXF-4600 using CXF approach, but this lead to dead end.
> CXF is reusing JAXB RI and it generates wrong XML schema for passed
> exception types
> (inheritance was lost in this case too).
> This leads me to a suspicion that this non standard JAXB RI
> exceptions processing
> is one of mandatory reasons why 'JAXWS 2.2 spec, Section 3.7 - Service
> Specific Exception'
> section exists.
> JAXB RI works like a charm for method types & parameters, but is
> crappy for exception types.
> Ok, end of brain dump :)
> Will anybody else share his ideas on this topic?
>
> Cheers,
>
> Richard
>
> PS: It seems we opened a can of worms in JAXWS spec.
>
> On 12/03/2012 08:36 AM, Richard Opalka wrote:
>> Clarification,
>>
>> was thinking little bit about it during the weekend.
>>
>> On 11/30/2012 03:20 PM, Richard Opalka wrote:
>>> Forgot to mention that this is related to CXF-4600 :(
>>>
>>> Follow up (thinking CXF way and for a while ignoring previous post):
>>>
>>> The sources we're going to talk about are located here:
>>>
>>> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/src/test/java/org/jboss/test/ws/jaxws/jbws3552
>>>
>>> We have the following exception hierarchy:
>>>
>>> @XmlAccessorType(XmlAccessType.FIELD) @XmlTransient
>>> ExtendedAdaptedExceptionCA -> AdaptedExceptionCA
>>> * code * message
>>> * description
>>> * complexObject
>>>
>>> CXF reuses JAXB for schema generation and this is the schema we're getting:
>>>
>>> <xs:element name="ExtendedAdaptedExceptionCA"
>>> type="tns:ExtendedAdaptedExceptionCA"/>
>>> <xs:complexType name="ExtendedAdaptedExceptionCA">
>>> <xs:sequence>
>>> <xs:element name="description" nillable="true" type="xs:string"/>
>>> <xs:element name="complexObject" nillable="true" type="xs:string"/>
>>> <xs:element name="message" nillable="true" type="xs:string"/>
>>> <xs:element name="code" nillable="true" type="xs:int"/>
>>> </xs:sequence>
>>> </xs:complexType>
>>>
>>> and
>>>
>>> <xs:element name="AdaptedExceptionCA" type="tns:AdaptedExceptionCA"/>
>>> <xs:complexType name="AdaptedExceptionCA">
>>> <xs:sequence/>
>>> </xs:complexType>
>>>
>>> In our humbly opinion because AdaptedExceptionCA is @XmlTransient annotated
>>>
>>> see:
>>> http://docs.oracle.com/javaee/6/api/javax/xml/bind/annotation/XmlTransient.html
>>>
>>> the above AdaptedExceptionCA definition generated by de facto "JAXB
>>> STANDARD" is wrong.
>>
>> Still valid claim that JAXB generates wrong XML schema.
>>
>>> If we'll ignore (will close all our eyes) the fact that inheritance is
>>> completely broken (what is completely wrong BTW)
>>
>> Above claim is wrong. @XmlTransient annotated objects cannot be mapped
>> to XML schema, so if exceptions inheritance hierarchy is not mapped to
>> XML, it is correct.
>>
>>> when mapped to XML then the above definition should at least look like:
>>>
>>> <xs:element name="AdaptedExceptionCA" type="xs:anyType"/>
>>> <!-- the below definition should never be generated -->
>>> <!--xs:complexType name="AdaptedExceptionCA">
>>> <xs:sequence/>
>>> </xs:complexType-->
>>
>> Still valid statement IMO.
>>
>>>
>>> WDYT?
>>>
>>> PS1: Just thinking loud :)
>>> PS2: Attached are generated WSDL sources.
>>>
>>> On 11/30/2012 02:53 PM, Richard Opalka wrote:
>>>> Hi CXF folks,
>>>>
>>>> Below is copy/paste from JAXWS 2.2 spec, Section 3.7 - Service Specific
>>>> Exception:
>>>> ---
>>>> 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.
>>>> ---
>>>>
>>>> I'm wondering why CXF isn't using generated 'exception' beans for JAXB
>>>> de/serialization & WSDL generation
>>>> but instead operate directly on top of exception objects? I know CXF is
>>>> passing TCK, but isn't it violating JAXWS spec.?
>>>> Most probably TCK tests doesn't cover this issue :(
>>>>
>>>> Cheers,
>>>>
>>>
>>
>>
>
>
--
Richard Opalka
Principal Software Engineer
JBoss, by Red Hat
Cell: +420 731 186 942
Re: Exceptions inheritance JAXB de/serialization issue
Posted by Richard Opalka <ro...@redhat.com>.
Hello CXF folks,
after googling, reading the specs. & blogs whole day
I have few additional findings.
I was playing little bith with JAXWS-RI today and
I see exception inheritance is broken there as well.
JAXWS RI according to JAXWS spec. requirement
generates exception 'beans' for all checked exceptions
that are not @WebFault annotated.
What I discovered is if I have the following
exceptions hierarchy:
SubException extends SuperException
* String a * String b
The JAXWS RI translates this to:
SubExceptionBean SuperExceptionBean
* String a * String b
* String b
and ...
Exactly, you're not blind! The inheritance
hierarchy is broken/eliminated in generated beans.
Another interesting issue I identified in JAXWS RI
is it ignores @XmlTransient on exceptions.
This said when exception 'beans' are generated for
checked exceptions not annotated with @WebFault,
the @XmlType and other similar JAXB sensitive annotations
are propagated from original exceptions to generated exception beans.
But @XmlTransient not. (http://java.net/jira/browse/JAXB-136)
OK, this was about how JAXWS RI works.
IMHO JAXWS spec. is very secret and silent in this exceptions area.
This probably resulted to fact Apache CXF implements it differently
than JAXWS RI does. I mean Apache CXF JAXB databinding is not using
generated exception 'beans' but rather operates on top of exception
objects instead.
I was trying to fix CXF-4600 using CXF approach, but this lead to dead end.
CXF is reusing JAXB RI and it generates wrong XML schema for passed
exception types
(inheritance was lost in this case too).
This leads me to a suspicion that this non standard JAXB RI
exceptions processing
is one of mandatory reasons why 'JAXWS 2.2 spec, Section 3.7 - Service
Specific Exception'
section exists.
JAXB RI works like a charm for method types & parameters, but is
crappy for exception types.
Ok, end of brain dump :)
Will anybody else share his ideas on this topic?
Cheers,
Richard
PS: It seems we opened a can of worms in JAXWS spec.
On 12/03/2012 08:36 AM, Richard Opalka wrote:
> Clarification,
>
> was thinking little bit about it during the weekend.
>
> On 11/30/2012 03:20 PM, Richard Opalka wrote:
>> Forgot to mention that this is related to CXF-4600 :(
>>
>> Follow up (thinking CXF way and for a while ignoring previous post):
>>
>> The sources we're going to talk about are located here:
>>
>> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/src/test/java/org/jboss/test/ws/jaxws/jbws3552
>>
>> We have the following exception hierarchy:
>>
>> @XmlAccessorType(XmlAccessType.FIELD) @XmlTransient
>> ExtendedAdaptedExceptionCA -> AdaptedExceptionCA
>> * code * message
>> * description
>> * complexObject
>>
>> CXF reuses JAXB for schema generation and this is the schema we're getting:
>>
>> <xs:element name="ExtendedAdaptedExceptionCA"
>> type="tns:ExtendedAdaptedExceptionCA"/>
>> <xs:complexType name="ExtendedAdaptedExceptionCA">
>> <xs:sequence>
>> <xs:element name="description" nillable="true" type="xs:string"/>
>> <xs:element name="complexObject" nillable="true" type="xs:string"/>
>> <xs:element name="message" nillable="true" type="xs:string"/>
>> <xs:element name="code" nillable="true" type="xs:int"/>
>> </xs:sequence>
>> </xs:complexType>
>>
>> and
>>
>> <xs:element name="AdaptedExceptionCA" type="tns:AdaptedExceptionCA"/>
>> <xs:complexType name="AdaptedExceptionCA">
>> <xs:sequence/>
>> </xs:complexType>
>>
>> In our humbly opinion because AdaptedExceptionCA is @XmlTransient annotated
>>
>> see:
>> http://docs.oracle.com/javaee/6/api/javax/xml/bind/annotation/XmlTransient.html
>>
>> the above AdaptedExceptionCA definition generated by de facto "JAXB
>> STANDARD" is wrong.
>
> Still valid claim that JAXB generates wrong XML schema.
>
>> If we'll ignore (will close all our eyes) the fact that inheritance is
>> completely broken (what is completely wrong BTW)
>
> Above claim is wrong. @XmlTransient annotated objects cannot be mapped
> to XML schema, so if exceptions inheritance hierarchy is not mapped to
> XML, it is correct.
>
>> when mapped to XML then the above definition should at least look like:
>>
>> <xs:element name="AdaptedExceptionCA" type="xs:anyType"/>
>> <!-- the below definition should never be generated -->
>> <!--xs:complexType name="AdaptedExceptionCA">
>> <xs:sequence/>
>> </xs:complexType-->
>
> Still valid statement IMO.
>
>>
>> WDYT?
>>
>> PS1: Just thinking loud :)
>> PS2: Attached are generated WSDL sources.
>>
>> On 11/30/2012 02:53 PM, Richard Opalka wrote:
>>> Hi CXF folks,
>>>
>>> Below is copy/paste from JAXWS 2.2 spec, Section 3.7 - Service Specific
>>> Exception:
>>> ---
>>> 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.
>>> ---
>>>
>>> I'm wondering why CXF isn't using generated 'exception' beans for JAXB
>>> de/serialization & WSDL generation
>>> but instead operate directly on top of exception objects? I know CXF is
>>> passing TCK, but isn't it violating JAXWS spec.?
>>> Most probably TCK tests doesn't cover this issue :(
>>>
>>> Cheers,
>>>
>>
>
>
--
Richard Opalka
Principal Software Engineer
JBoss, by Red Hat
Cell: +420 731 186 942
Re: Exceptions inheritance JAXB de/serialization issue
Posted by Richard Opalka <ro...@redhat.com>.
Clarification,
was thinking little bit about it during the weekend.
On 11/30/2012 03:20 PM, Richard Opalka wrote:
> Forgot to mention that this is related to CXF-4600 :(
>
> Follow up (thinking CXF way and for a while ignoring previous post):
>
> The sources we're going to talk about are located here:
>
> http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/src/test/java/org/jboss/test/ws/jaxws/jbws3552
>
> We have the following exception hierarchy:
>
> @XmlAccessorType(XmlAccessType.FIELD) @XmlTransient
> ExtendedAdaptedExceptionCA -> AdaptedExceptionCA
> * code * message
> * description
> * complexObject
>
> CXF reuses JAXB for schema generation and this is the schema we're getting:
>
> <xs:element name="ExtendedAdaptedExceptionCA"
> type="tns:ExtendedAdaptedExceptionCA"/>
> <xs:complexType name="ExtendedAdaptedExceptionCA">
> <xs:sequence>
> <xs:element name="description" nillable="true" type="xs:string"/>
> <xs:element name="complexObject" nillable="true" type="xs:string"/>
> <xs:element name="message" nillable="true" type="xs:string"/>
> <xs:element name="code" nillable="true" type="xs:int"/>
> </xs:sequence>
> </xs:complexType>
>
> and
>
> <xs:element name="AdaptedExceptionCA" type="tns:AdaptedExceptionCA"/>
> <xs:complexType name="AdaptedExceptionCA">
> <xs:sequence/>
> </xs:complexType>
>
> In our humbly opinion because AdaptedExceptionCA is @XmlTransient annotated
>
> see:
> http://docs.oracle.com/javaee/6/api/javax/xml/bind/annotation/XmlTransient.html
>
> the above AdaptedExceptionCA definition generated by de facto "JAXB
> STANDARD" is wrong.
Still valid claim that JAXB generates wrong XML schema.
> If we'll ignore (will close all our eyes) the fact that inheritance is
> completely broken (what is completely wrong BTW)
Above claim is wrong. @XmlTransient annotated objects cannot be mapped
to XML schema, so if exceptions inheritance hierarchy is not mapped to
XML, it is correct.
> when mapped to XML then the above definition should at least look like:
>
> <xs:element name="AdaptedExceptionCA" type="xs:anyType"/>
> <!-- the below definition should never be generated -->
> <!--xs:complexType name="AdaptedExceptionCA">
> <xs:sequence/>
> </xs:complexType-->
Still valid statement IMO.
>
> WDYT?
>
> PS1: Just thinking loud :)
> PS2: Attached are generated WSDL sources.
>
> On 11/30/2012 02:53 PM, Richard Opalka wrote:
>> Hi CXF folks,
>>
>> Below is copy/paste from JAXWS 2.2 spec, Section 3.7 - Service Specific
>> Exception:
>> ---
>> 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.
>> ---
>>
>> I'm wondering why CXF isn't using generated 'exception' beans for JAXB
>> de/serialization & WSDL generation
>> but instead operate directly on top of exception objects? I know CXF is
>> passing TCK, but isn't it violating JAXWS spec.?
>> Most probably TCK tests doesn't cover this issue :(
>>
>> Cheers,
>>
>
--
Richard Opalka
Principal Software Engineer
JBoss, by Red Hat
Cell: +420 731 186 942
Re: Exceptions inheritance JAXB de/serialization issue
Posted by Richard Opalka <ro...@redhat.com>.
Forgot to mention that this is related to CXF-4600 :(
Follow up (thinking CXF way and for a while ignoring previous post):
The sources we're going to talk about are located here:
http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/src/test/java/org/jboss/test/ws/jaxws/jbws3552
We have the following exception hierarchy:
@XmlAccessorType(XmlAccessType.FIELD) @XmlTransient
ExtendedAdaptedExceptionCA -> AdaptedExceptionCA
* code * message
* description
* complexObject
CXF reuses JAXB for schema generation and this is the schema we're getting:
<xs:element name="ExtendedAdaptedExceptionCA"
type="tns:ExtendedAdaptedExceptionCA"/>
<xs:complexType name="ExtendedAdaptedExceptionCA">
<xs:sequence>
<xs:element name="description" nillable="true" type="xs:string"/>
<xs:element name="complexObject" nillable="true" type="xs:string"/>
<xs:element name="message" nillable="true" type="xs:string"/>
<xs:element name="code" nillable="true" type="xs:int"/>
</xs:sequence>
</xs:complexType>
and
<xs:element name="AdaptedExceptionCA" type="tns:AdaptedExceptionCA"/>
<xs:complexType name="AdaptedExceptionCA">
<xs:sequence/>
</xs:complexType>
In our humbly opinion because AdaptedExceptionCA is @XmlTransient annotated
see:
http://docs.oracle.com/javaee/6/api/javax/xml/bind/annotation/XmlTransient.html
the above AdaptedExceptionCA definition generated by de facto "JAXB
STANDARD" is wrong.
If we'll ignore (will close all our eyes) the fact that inheritance is
completely broken (what is completely wrong BTW)
when mapped to XML then the above definition should at least look like:
<xs:element name="AdaptedExceptionCA" type="xs:anyType"/>
<!-- the below definition should never be generated -->
<!--xs:complexType name="AdaptedExceptionCA">
<xs:sequence/>
</xs:complexType-->
WDYT?
PS1: Just thinking loud :)
PS2: Attached are generated WSDL sources.
On 11/30/2012 02:53 PM, Richard Opalka wrote:
> Hi CXF folks,
>
> Below is copy/paste from JAXWS 2.2 spec, Section 3.7 - Service Specific
> Exception:
> ---
> 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.
> ---
>
> I'm wondering why CXF isn't using generated 'exception' beans for JAXB
> de/serialization & WSDL generation
> but instead operate directly on top of exception objects? I know CXF is
> passing TCK, but isn't it violating JAXWS spec.?
> Most probably TCK tests doesn't cover this issue :(
>
> Cheers,
>
--
Richard Opalka
Principal Software Engineer
JBoss, by Red Hat
Cell: +420 731 186 942