On 22 June 2010 11:25, Leo Romanoff <romixlev_at_yahoo.com> wrote:
> > So, anything below the xs:any must be handled must be handled with the
> > multi-stage approach.
>
> I understand. Assume that I know at which sub-tree JAXB could kick in again
> and I extract this sub-tree into a DOM element. Then I guess I have to use
> jaxbContext.createUnmarshaller() and let it unmarshall the sub-tree. In
> principle, it should work, as this subtree represents a JAXB-annotated
> type.
> Is it what you mean by the multi-stage approach?
>
Yes.
>
> But I see one possible complication that is not so obvious for me:
> In my real use-case I use @XmlIdREF and @XmlId annotations. They work find
> if JAXB reads the whole XML document at once and all references are
> resolved
> without any problems. But if I go for the multi-stage approach, I can
> easily
> imagine that references from parent JAXB-friendly element to JAXB-friendly
> elements inside xs:any element (and vice versa) cannot be resolved out of
> the box, as these are two different documents from JAXB's point of view.
> If
> this is the case, do you have an idea how this can be solved? May be some
> custom entity references resolvers or something like that can be used?
>
One thing up front: You can always use a plain String value to represent
element linkage. You may *have* to do this when linkage is between different
documents. Then you are confronted with the issue of needing two fields in
the element whence the link originates - one for the pseudo id and the other
one for the object reference.
If you consider going beyond the "official" JAXB API, there is the class
com.sun.xml.bind.IDResolver
and its javadoc describes how to use this vendor-specific backdoor.
The warning of its potential volatility is there, in caps. I've never used
this, so I can't give you any hints.
But ID/IDREF, even without cross-document linkage, isn't quite so simple.
Not using it is disastrous in cyclic linkage, and bad with multiple
references;
if you do use it, you must take care to have to targeted elements where they
are "hard" referenced.
-W
>
> Thanks again,
> Leo
>
>
> Wolfgang Laun-2 wrote:
> >
> > On 22 June 2010 01:10, Leo Romanoff <romixlev_at_yahoo.com> wrote:
> >
> >>
> >> Or is it like this: Once you have an xsd:anyType element, everything
> >> inside
> >> this element, including any JAXB-aware subelements, cannot be parsed by
> >> JAXB
> >> and is represented also as a DOM element?
> >>
> >>
> > There is no reason for JAXB to try and find some sub(-sub(-sub))-tree
> > where
> > it
> > might kick in again and marshal (or, worse, unmarshal). So, anything
> below
> > the xs:any must be handled must be handled with the multi-stage approach.
> >
> > -W
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Custom-mapping-for-Maps-in-JAXB-tp28779221p28957897.html
> Sent from the java.net - jaxb users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>