[
https://issues.apache.org/jira/browse/CXF-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13877474#comment-13877474
]
Andi Scharfstein edited comment on CXF-5481 at 1/21/14 2:06 PM:
----------------------------------------------------------------
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 7)
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";
This issue can be considered "fixed" once the response data can be validated
against the generated WSDL without errors.
was (Author: andi.scharfstein):
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 7)
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 errors.
> 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
>
> Attachments: CXF-5481.zip
>
>
> 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)
