[
https://issues.apache.org/jira/browse/CXF-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875187#comment-13875187
]
Daniel Kulp commented on CXF-5481:
----------------------------------
Yea. Maven is always preferred, but Ant can work.
> 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)
