cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-5481) Context-dependent ordering of complex type elements
Date Fri, 17 Jan 2014 19:42:21 GMT

    [ https://issues.apache.org/jira/browse/CXF-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875178#comment-13875178
] 

Daniel Kulp commented on CXF-5481:
----------------------------------

If you could create a test case for this, that would be a huge help.

> Context-dependent ordering of complex type elements
> ---------------------------------------------------
>
>                 Key: CXF-5481
>                 URL: https://issues.apache.org/jira/browse/CXF-5481
>             Project: CXF
>          Issue Type: Bug
>          Components: Aegis Databinding
>    Affects Versions: 2.7.8
>            Reporter: Andi Scharfstein
>             Fix For: NeedMoreInfo
>
>
> After creating and deploying a Java-first web service (SOAP, XML, Aegis databinding),
CXF generates data that doesn't validate against the WSDL that is auto-generated by CXF. The
type definitions look something like this:
> <xsd:complexType name="SomeComplexType">
> 	<xsd:complexContent>
> 		<xsd:extension base="tns:AbstractExtensionBase">
> 			<xsd:sequence>
> 				<xsd:element minOccurs="0" name="anElement" nillable="true" type="xsd:string"/>
> 				<xsd:element minOccurs="0" name="otherElement" nillable="true" type="xsd:string"/>
> 			</xsd:sequence>
> 		</xsd:extension>
> 	</xsd:complexContent>
> </xsd:complexType>
> <xsd:complexType name="AbstractExtensionBase">
> 	<xsd:sequence>
> 		<xsd:element minOccurs="0" name="baseElement" nillable="true" type="xsd:string"/>
> 	</xsd:sequence>
> </xsd:complexType>
> The problem is that there seem to be two different modes for generating instances of
the complex type in a service response. In the first, the elements are ordered as follows:
> 1. baseElement
> 2. anElement
> 3. otherElement
> Elements inherited from the abstract base class are rendered first, then the elements
from the complex type are rendered in alphabetical order. The second mode is as follows:
> 1. anElement
> 2. baseElement
> 3. otherElement
> Here, everything is rendered out in alphabetical order, including elements of the baseclass.
However, this element order doesn't seem to conform to the type definition given in the WSDL,
and a variety of parsers don't want to to deal with this kind of behaviour. As an example,
SoapUI parses the output correctly but emits the following warning when validating the response
agains the WSDL:
> line 32: Expected element 'otherElement' instead of 'baseElement' here in element SomeComplexType
> Other products stop parsing the generated output completely, which of course is a no-go
in a production setting.
> I have not been able to determine the trigger for the different modes of generating the
objects. The first one seems to be used when the object is delivered as a root-level type,
while the second one is used when the object is delivered as a child of some other complex
type, in my setting as part of an array that is in turn part of another object. I wouldn't
necessarily describe the type hierarchy as complex, but obviously something is happening here
that Aegis doesn't seem to deal with all that well. I hope this can be fixed, otherwise Java-first
web service development doesn't strike me as very practical.
> Please notify me if you need further examples / explanations.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message