See inline.
On 23/12/2011, tim.quinn_at_oracle.com <tim.quinn_at_oracle.com> wrote:
[snip]
>
> Suppose I have
>
> <xsd:choice maxoccurs="unbounded">
> <xsd:element name="a" type="aType"/>
> <xsd:element name="b" type="bType"/>
> </xsd:choice>
>
[snip]
> What JAX-B generates is
>
> public List<JAXBElement<?>> get...
>
> where it generates the method name.
>
> First, what I would really like is for JAX-B to generate
>
> List<AType> getA() {...}
>
> List<BType> getB() {...}
This loses information which is inherently and unavoidably imposed
by the XML data model, i.e. the relative ordering of <a>'s and <b>'s
within their containing parent. If you aren't interested in a relative
ordering, redefine the XML schema without <xs:choice>.
>
> Second, given that it does not do that I understand that a handler can
> help me here. What strikes me is that JAX-B has all the information at
> build-time that's needed to write the handler. It would be far better
> at doing that than I would be doing so manually.
That's an interesting thought but the generator won't be able to generate
the code doing the actual processing for you. So, how would that be merged
into the generated stuff?
[snip]
Cheers & season greetings
Wolfgang