Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.7.8
-
None
-
Unknown
Description
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.