On 23 June 2010 10:59, Leo Romanoff <romixlev_at_yahoo.com> wrote:
>
> > 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 that threading would be an issue. Creating an (un)marshaller
from a JAXBContext does not change the latter.
>
> > 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?
>
Knowing the JAXBContext that brings you to some element where you need
to start another Unmarshaller may or may not guarantee that this context
is still useful unless you know that all your top-level elements (also the
ones
that aren't really top-level) can be unmarshalled with a single JAXBContext.
Then, by induction, it'll be just one JAXBContext anyway ;-)
> 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?
>
If your Adapters have to manage "multi-stage" their generic library will
have
to include a way of determining the right JAXBContext and obtaining it
from some registry object. They aren't tun-of-the-mill adapters any more...
-W
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>