The root of this and several similar problems is that the XML Schema for
data serialization differs considerable from the data model of a Java
object hierarchy. (I could expand on this but the end of the year is nigh.)
Of course, given enough time and money Su - I do beg your pardon, it's
Oracle now, isn't it ;-) - could enhance the JAXB spec and its reference
implementation to provide convenience methods for alternative
interpretations of XML Schema typing concepts. In this case, a simple
"disregard order" customization would do the trick. (I think the very nice
guys in Prague would be prepared to have a go at it!)
Cheers
Wolfgang
On 23 December 2011 17:41, Tim Quinn <tim.quinn_at_oracle.com> wrote:
>
> On Dec 23, 2011, at 10:05 AM, Wolfgang Laun wrote:
>
> 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>.
>
>
> And if I don't have control over the schema?
>
> It's interesting that you say that because, in this case, the comments in
> the schema (it's the Java EE schema for web apps) indicate that the reason
> for using choice is to allow the child elements to appear in any order, and
> in this specific case at least the ordering does not matter. Of course in
> some cases the order in which they appear might still be important, even
> though the schema allows them to appear in any order.
>
> Note that I did not mean to say that I wanted JAX-B to generate *only* the
> getA and getB methods. JAX-B could happily generate the getAorB method as
> well which would preserve the ordering. But by generating getA and getB
> for me JAX-B would allow me concentrate on using the content rather than
> writing a handler to get to the content and type it appropriately so I
> could then actually use it.
>
>
>
>
> >
> > 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?
>
> I suppose JAX-B could generate an abstract handler with abstract methods
> processA(A a), processB(B b), etc. The element-specific names could be
> necessary (rather than just generating process(A a) and process(B b) in
> case A and B both turn out to be String, for example). There could be
> issues with this approach I'm not seeing but if so I'm sure there would be
> solutions to them as well!
>
> - Tim
>
>