Hi Wolfgang,
Thanks for your reply. It is very informative and useful, as usual.
See some comments below.
>> 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.
OK. I see the point. But in the discussed case it is still the same
document, but with some "unknown" for JAXB tags in between.
>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.
This sounds interesting. It is a pity that it is vendor specific.
>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.
Yes. ID/IDREF is not so simple :-(
One more question related to the discussion:
We have now discussed different strategies to resolve references.
But one part of the solution is also to parse some xsd:any sub-elements,
that are known to JAXB. For that a new JAXBUnmarshaller should be created
from a JAXBContext (or current one could be reused???). But AFAIK, inside
XmlAdapter's marshal and unmarshal methods there is no way to access the
current JAXBContext or current JAXBMarhsaller/JAXBUnmarshaller. Now, how can
I create/get a proper JAXBContext if I don't know the current one? After all
this new context to be used for staged approach should cover exactly the
same set of JAXB-annotated classes as the current one, or? And if such an
XmlAdapter should become a reusable class, it should not rely on a-priory
knowledge about user-defined annotated JAXB-classes. Therefore, IMHO, it
should obtain this information at run-time from the current context. And the
fact, that @XmlJavaTypeAdapter is an annotation and can take only
compile-time parameters, makes it impossible to pass any JAXB context via
this channel.
So, how the proper JAXBContext can be obtained at run-time? Is it possible
at all with JAXB?
Do you have any ideas about that?
Thanks,
Leo
--
View this message in context: http://old.nabble.com/Custom-mapping-for-Maps-in-JAXB-tp28779221p28962855.html
Sent from the java.net - jaxb users mailing list archive at Nabble.com.