cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andi Scharfstein (JIRA)" <>
Subject [jira] [Updated] (CXF-5481) Context-dependent ordering of complex type elements
Date Tue, 21 Jan 2014 13:56:19 GMT


Andi Scharfstein updated CXF-5481:


Okay. Please find attached my sample project reproducing the bug. Sorry about the libs, I
couldn't spend a lot of time on finding out which ones could be safely removied so I left
most of them in. Yes, I know Maven would be better, sadly that's not an option for this project
right now.

Steps to reproduce the problem:

1) Unzip. You'll find a folder containing an Eclipse Ant project demonstrating the bug.

2) Add a recent CXF Jar to the WebContent/WEB-INF/lib folder (tested with 2.7.7)

3) Run the Ant build (target "war" is default, should do everything you need).

4) Deploy the resulting WAR file in an application server of your choosing (tested on Tomcat

5) Browse to <tomcat-url>/services/CXF5481Service?wsdl and verify everything works correctly.

Now you have a web service set up that displays the described behaviour. You can verify this
by doing the following:

1) Create a SoapUI project using the above WSDL

2) Call the method  "getExportObject"

3) Right-click on the reponse data and choose "Validate". There should be three errors of
the form
"line 24: Expected element 'otherElement@http://data.webservice.cxf' instead of 'baseElement@http://data.webservice.cxf'
here in element SomeComplexType@http://data.webservice.cxf"

The bug is fixed once the response data can be validated against the generated WSDL without

> Context-dependent ordering of complex type elements
> ---------------------------------------------------
>                 Key: CXF-5481
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: Aegis Databinding
>    Affects Versions: 2.7.8
>            Reporter: Andi Scharfstein
>             Fix For: NeedMoreInfo
>         Attachments:
> 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

View raw message