Open o0oGnas opened 3 years ago
JAXB can't 'guess' your intended object model. If you want a sequence of 'paired' items, you should make a complex type and a collection of the complex type.
Try this instead:
<complexType name="Number">
<attribute name="number" type="int" />
<attribute name="text" type="string" />
</complexType>
<complexType name="Numbers">
<sequence>
<element name="Number" type="ns:Number" maxOccurs="unbounded"/>
</sequence>
</complexType>
@mattrpav I think you didn't fully understand my issue. I'm not asking JAXB to guess my intended object model. I'm asking it to generate unbounded sequences as lists of wrapper objects which wrap the elements inside each sequence. Creating a complex type to wrap the elements and declaring it as a list with "unbounded" will not solve my problem because the structure would be slightly different from the unbounded sequence. In your suggestion the XML would look something like
<numbers>
<number>
<number>1</number>
<text>one</number>
</number>
<number>
<number>2</number>
<text>two</text>
</number>
</numbers>
which is different from what I have as input and thus cannot be unmarshalled by JAXB without doing some hacky workarounds. While I agree this would be the better way to represent the data, it's unfortunately what I have to live with as the structure is defined by a third party and not me.
Suppose we have a complex type in a schema like this.
By default XJC will generate a
List<JAXBElement>
inside class Numbers to represent the sequence. When used with simplify plugin, it becomes 2 separate listsList<Integer> number
andList<String> text
. While this works for unmarshalling XML data, it doesn't keep the interconnected relationship between eachnumber
andtext
element as defined by the schema, which can make it awkward to program with. Furthermore, when the same object is marshalled back into XML, allnumber
elements will be placed before alltext
elements, which is wrong.For example, XML data such as
would be marshalled back as
My proposed enhancement for this use case is as follows:
Sequence
inside generatedNumbers
classnumber
asInteger
andtext
asString
.Numbers
class would instead contain aList<Numbers.Sequence>
.e.g.
One problem I can think of with this approach is when the
complexType
happens to have an attribute also namedsequence
. In such cases I think prefixing or suffixing the name of the fieldList<Numbers.Sequence> sequence
with something would suffice.