Thanks for your reply Kohsuke.
I realize this is appropriate XML ID/IDREF semantics, but unfortunately
it is not quite how I want it to work.
Could I possibly make use of the XmlAdapter and @XmlJavaTypeAdapter
mechanism to work around this problem? (solution #1) For example, the
XmlAdapter could hand my AppleAdapter the string "myFruit". The
AppleAdapter would know to retrieve the appropriate Apple object and
return it.
This isn't exactly ideal - in the example I gave previously the Apple
object may not have been constructed by the time the XmlAdapter is
invoked - therefore I would have to carefully load my objects in the
appropriate order and there would still be limitations.
What would be ideal (solution #2) for my situation would be if JAXB
basically kept a mapping from <class type, ID> to the object being
constructed. Then if it was setting a property like setApple( Apple
myApple ), it would know to only look in IDREF list under <Apple.class,
"myFruit"> Of course, this doesn't exactly follow the ID/IDREF
semantics, but other than the idea mentioned above I don't have many
good ideas.
I guess another solution (solution #3) would be to build up an
XML-specific tree and then convert that into a domain-specific tree.
(as you mentioned) But this requires a separate processing layer in
between the XML binding and application layer - a post-XML binding
layer.
Please let me know what you think about solution #1 and #2.
Thanks,
Jeremy
On Mon, 11 Jul 2005 12:21:53 -0700, "Kohsuke Kawaguchi"
<Kohsuke.Kawaguchi_at_Sun.COM> said:
> Jeremy Haile wrote:
> > When you unmarshal the following XML file, Castor would sometimes try to
> > set the Apple field with the Orange or visa-versa, since it only looks
> > at the XML ID:
> >
> > <myFruits>
> > <basketOfFruit apple="myFruit" orange="myFruit" />
> > <apple name="myFruit"/>
> > <orange name="myFruit"/>
> > </myFruits>
>
>
>
> > So - now to my questions:
> > 1) Has anyone else experienced these types of problems? Any ideas or
> > solutions?
>
> I think this is a general problem. It would be probably nice if the JAXB
> RI / spec can generalize the ID processing. Applications can then use
> this hook to plug their own reference integrity semantics.
>
> The work around would be for you to resolve your pseudo-IDs into objects
> within your object model (by hiding them behind the getApple() method),
> or post-process the tree and fix up those references.
>
> > 2) Is JAXB 2.0 smarter than Castor in this regard?
>
> No. This is a validity violation, and unfortunately JAXB does not handle
> this in a way you'd hope it to do. I hope you'd understand that it is
> the correct handling of ID/IDREF semantics.
>
>
> > 3) Does JAXB 2.0 provide a mechanism by which to deal with these types
> > of problems.
>
> Not right now, but this sounds like an interesting area to explore.
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com