Forum Discussion

tstmartin's avatar
tstmartin
Contributor
11 years ago

WS response elements alphabetized - fails xsd validation

We're using soapUI Pro 4.6.4, and Oracle Weblogic.

Our webservices work as expected on weblogic 10.3; the responses can be validated against the schema. We have recently upgraded to Weblogic 12. We now get responses which contain the proper elements, but the elements have been ordered alphabetically, which gives us schema validation errors.

Response running under Weblogic 10.3 - this will validate against the schema.
<response>
    <Aelement>data</Aelement>
    <belement>data</belement>
    <celement>data</celement>
    <Zelement>data</Zelement>
</response>

Response running under WL 12 - this will not validate because the Zelement is
out of proper sequence.
<response>
    <Aelement>data</Aelement>
    <Zelement>data</Zelement>
    <belement>data</belement>
    <celement>data</celement>
</response>


Any idea what's changed to make this happen?

More important, any suggestions what we can do to get the responses to be returned in the the order specified in the xsd files?

Thanks. If it's not something silly we're overlooking, we don't understand why we can't find anything ont eh web about this ; I'd expect an uproar...

5 Replies

Sort By
  • PaulDonny's avatar
    PaulDonny
    Regular Contributor
    11 years ago
    This sounds like an issue within the code itself, nothing to do with SoapUI. If it is causing errors and issues, I would recommend a defect be filed and assigned to your Development team in order to fix the issue.

    I might be wrong though, if you have a good relationship with your Dev team, contact them and ask them what is going on.
  • tstmartin's avatar
    tstmartin
    Contributor
    11 years ago
    Thanks for the reply Paul.

    Yes , we (both QA & Dev team) agree it is almost certainly not soapUI. That's why I posted in the general forum. Was hoping someone might have insight into why the webservices are building the response according to some lexical ordering instead of following the xsd sequence ...

    hopefully something along the lines of 'with the new xyz library that comes with the new Weblogic server you have to configure the foo switch ' or something

    As far as we can tell, our webservices code has not changed, nor has our soapUI version or test projects.
  • PaulDonny's avatar
    PaulDonny
    Regular Contributor
    11 years ago
    From the way it looks, it was always sorted alphabetically and the new Weblogic Version treats alphabetically differently. The first request is in an absolute alphabetical order ignoring case and the new one does not ignore case. This seems like an issue in the code and ultimately is a defect.

    This most likely has to deal with Java EE 5 vs Java EE 6, though there is many different possible things that could cause this.
  • tstmartin's avatar
    tstmartin
    Contributor
    11 years ago
    Thanks Paul!

    Good insight about always having been alphabetic, one we overlooked since our xsd is ordered the same way.
    But that got me thinking about order and case, and made me realize another difference between what used to work and what doesn't now.

    The previous setup (working) was running on Unix; for lack of servers, the current version setup (failing) is installed on Windows 7.

    Possibly significant information that I neglected to include - my bad!

    Anyway, the OS difference gives us something else to look at.
    I'll be back when we know more.

    -tom
  • tstmartin's avatar
    tstmartin
    Contributor
    11 years ago
    Summary I got from our developers -
    prior to Java7/J2EE5/WL12 Weblogic generated the soap response in A-Z (ignore case) order by default;
    J7/J2EE5/WL12 generates in A-Z(case sensitive) order by default.
    The annotation @XmlAccessorOrder(XmlAccessOrder.ALPHABETICAL) should generate the A-Z(case sensitive) wsdl, but for some
    reason did not.
    Our build included a wsgen setting of xendorsed="true" ; changing this setting to 'false' allows the annotation to be honored and
    the result is a case sensitive wsdl which we use on the client side to validate against the WS response.

    Apologies I dont have the time or understanding to post a better explanation; hopefully there are enough clues there to help the next person who hits this.

    -tom