Andi Scharfstein created CXF-5481:
-------------------------------------
Summary: 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
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)
