Hi Wolfgang,
>> 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???).
> Don't use the same Unmarshaller twice at the same time.
OK. Point taken!
>> 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?
> In any given application, packages and/or classes define the set of
> available JAXBContexts.
> At the point where you create your (Un)Marshaller you ought to
> know the Java Class name. Map them or their package names to the set
> of JAXBContexts you need and access this global Map. Create the new
> (Un)Marshaller from it.
OK. So, you propose to use a global mapping from classes to JAXBContexts and
use this global mapping inside such a multi-stage solution. This is of
course an option. A bit too global eventually, but would work. I'm not quite
sure if there would be any issues with class-loaders, multi-threadint, etc
when it is used inside e.g. JavaEE environment. But this is another issue.
> I don't think it's worth to have this "root" context object passed down
> the call tree, just in case some callback might need this. It may not be
> convenient (ot even possible - think of duplicate XML tags bound to
> different types in different places) to use the "root" context down there,
> so a more general mechanism would be necessary.
I see your point regarding passing down the call tree. Actually, I also did
not mean it in the direct sense. I had in mind something like ThreadLocal
context or some other kind of context with JAXB infos that can be accessed
or injected on demand down the call tree if required. Specifically, such a
context could contain information about "current" JAXBContext.
BTW, I do not mean that it is the same "current" context all the way down.
It could change along this path, if required. But my idea was that unless
stated/required otherwise the xsd:any sub-tree JAXB parsing should continue
with the same set of classes like the one described by the last used
JAXBContext in this call-tree. Or do you say in you comment above that this
logic is broken?
With your nice global class->JAXBContext mapping approach, I still cannot
see how I know in a generic library for multi-stage JAXB parsing (like e.g.
the JsonMapAdapter class from previous messages) at the time when it is
invoked (e.g. implicitly, as a result of JAXWS call) which JAXBContext is to
be used right now?
Thanks,
-Leo
--
View this message in context: http://old.nabble.com/Custom-mapping-for-Maps-in-JAXB-tp28779221p28969237.html
Sent from the java.net - jaxb users mailing list archive at Nabble.com.