Thanks for the quick reply.
> 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?
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?
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.