Just FYI another related discussion: http://mail-archives.apache.org/mod_mbox/cxf-users/200903.mbox/%[email protected]%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
