JAXB UnMarshall Collection element order - continued

I am aware that almost the same question has been asked before (here). Despite that there is one interesting answer, there is still a loose end 开发者_开发百科(in the case of unmarshalling) that also seems to apply in our case.

Here's our situation: we're parsing SOAP messages, the body of which is structured like this:

<complexType name="Body">
  <complexContent>
    <restriction base="{http://www.w3.org/2001/XMLSchema}anyType">
      <sequence>
        <element ref="{http://[message=spec url]"/>
      </sequence>
    </restriction>
  </complexContent>
</complexType>

Until now, we have assumed that the order of the would be preserved in the (Array)Lists that result from the unmarshalling process. The elements are then written to a table and processed further in PL/SQL procedures. This is usually not sensitive to the order of the elements within a sequence. It can happen thought that there are two elements in the SOAP message that refer to the same object. This is an error. It's caught in the PL/SQL code, which deals with it by logging the situation and rejecting the second element.

Our problem now is that, very rarely and (until now) completely non-reproducible, not the second element (as seen in the SOAP message) is rejected, but the first. Seen from the PL/SQL code, this can only happen if the data, that represent the elements in case, are being read in the wrong order (compared again to how they appear in the message).

Therefore, I was wondering if this situation might arise because the order of the marshalled elements is not explicitly defined. In the answer to the above-mentioned question it looks like the order is defined in the case of marshalling with JAXB. The - as yet unanswered - question (by chahuistle) whether this is also the case for unmarshalling, is not yet answered.

I'd appreciate any help!

Note: I'm the EclipseLink JAXB (MOXy) lead, and a member of the JAXB (JSR-222) expert group.

I haven't found the exact mention in the spec, but the intention is that order be maintained. This is the reason that the main collection type used by JAXB is java.util.List.

Until now, we have assumed that the order of the would be preserved in the (Array)Lists that result from the unmarshalling process.

The MOXy implementation of JAXB will build a list based on the ordering of the elements returned by the underlying XML parser (DOM, SAX, StAX). I can't imagine any JAXB implementation behaving differently, as it would be harder to implement and less intuitive to the users.

Therefore, I was wondering if this situation might arise because the order of the marshalled elements is not explicitly defined.

The MOXy implementation of JAXB will marshal objects based on the ordering on objects in the List. Again I can't imagine any JAXB implementation behaving differently as it would be harder to implement and less intuitive.

You can specify this behavior in globalBindings declaration.

I'm assuming you are generating Java classes from the XSD files using XJC. Here is the most important part of the globalBindings element:

<globalBindings>
  [ collectionType = "collectionType" ]
  [ fixedAttributeAsConstantProperty  = "true" | "false" | "1" | "0" ]
  [ generateIsSetMethod  = "true" | "false" | "1" | "0" ]
  [ enableFailFastCheck = "true" | "false" | "1" | "0" ]
  [ choiceContentProperty = "true" | "false" | "1" | "0" ]
  [ underscoreBinding = "asWordSeparator" | "asCharInWord" ]
  [ typesafeEnumBase = "typesafeEnumBase" ]
  [ typesafeEnumMemberName = "generateName" | "generateError" ]
  [ enableJavaNamingConventions = "true" | "false" | "1" | "0" ]
  [ bindingStyle = "elementBinding" | "modelGroupBinding" ]
  [ <javaType> ... </javaType> ]*
</globalBindings> 

*collectionType can be either indexed or any fully qualified class name that implements java.util.List.

I'm guessing setting it to indexed should solve all problems.

Here is a link for spec. document (take a look at section 7.5 and 6.12 (and subparagraphs) or take a look at this tutorial