I opened a Jira so we have a place to share ideas and patches:
https://issues.apache.org/jira/browse/WINK-68
mike
From: Nicholas L Gallardo/Austin/i...@ibmus
To: [email protected]
Date: 07/08/2009 10:46 PM
Subject: Re: default JAXB context resolver?
> Looking at the Wink code today, the MessageBodyReader/Writer
> for JAXB stuff actually attempts to find the JAXBContext itself
> internally.
Yep, looks like AbstractJAXBProvider just holds on to a static map of those
contexts based on the Class. I'm assuming that Class is the entity
parameter or return type on the method signature.
It might actually be as simple as storing the static map of JAXBContexts in
the new resolver and just going from there. That map uses a Class<?> for
its key. This is good because it avoids the conflicts created by
JAXBContexts that support the same config, but were created on different
threads/from different Classloaders.
-Nick
Nicholas Gallardo
WebSphere - REST & WebServices Development
[email protected]
Phone: 512-286-6258
Building: 903 / 5G-016
Inactive hide details for Bryant Luk <[email protected]>Bryant Luk
<[email protected]>
Bryant Luk
<bryant....@gm
ail.com>
To
07/08/2009
10:18 PM [email protected]
che.org
Please respond to cc
[email protected]
Subject
Re: default JAXB
context resolver?
I did a quick peek again at this code.
One difference between the two implementations is that the IBM
implementation put the JAXBContextResolver on the list of
ContextResolver<JAXBContext> so it would show back up in the
Providers.getContextResolver() (at the tail end using user context
resolvers before built-in ones). Looking at the Wink code today, the
MessageBodyReader/Writer for JAXB stuff actually attempts to find the
JAXBContext itself internally.
The spec is kind of vague on this, but I don't see any obvious harm in
having a ContextResolver<JAXBContext> available as a standard
built-in, and I think application developers would like to know what
JAXBContext we would be using in the Reader/Writer. This isn't
exactly something I would lightly change later since even the
slightest change in behavior IMO could cause some random bug to pop
up, so making it "public" by putting it on the ContextResolver list
shouldn't be too bad. I'm probably missing something tho.
btw, I think Doug Larson may have had something to say about the
MessageBodyReader/Writer<JAXB...> code too. Dunno if he's back yet.
Thoughts?
On Wed, Jul 8, 2009 at 6:52 PM, Nicholas L Gallardo<[email protected]>
wrote:
> Mike,
>
> You're saying make a system level ContextResolver available so that we
can
> re-use instances and so users don't have to create one. I think that's
good.
> Take a look at this::
>
>
https://svn.apache.org/repos/asf/incubator/wink/contrib/ibm-jaxrs/src/com/ibm/ws/jaxrs/resolver/JAXBContextResolver.java
>
> Dustin created a system level JAXBContextResolver hid all of the caching
of
> the JAXBContext instances. The resolver is injected into the JAXB related
> Providers (as is already done in the current code) and they are able to
> share JAXBContext instances. I think Michael Elman (btw, can we just call
> you "Mike" and Michael E. "Michael"?) made a comment earlier about liking
> the JAXBContext caching mechanism. This is a good way to pull that over.
>
> -Nick
>
>
> Nicholas Gallardo
> WebSphere - REST & WebServices Development
> [email protected]
> Phone: 512-286-6258
> Building: 903 / 5G-016
> Michael Rheinheimer/Austin/i...@ibmus
>
>
> Michael Rheinheimer/Austin/i...@ibmus
>
> 07/08/2009 05:12 PM
>
> Please respond to
> [email protected]
>
> To
> [email protected]
> cc
>
> Subject
> default JAXB context resolver?
>
>
> Team,
>
> We had previously discussed implementing a default JAXB context resolver
to
> better hand JAXB contexts. As far as I can tell, there are no default
> "system" context resolvers loaded in WINK; only the context resolvers
> defined by an application are available. For JAXB, however, it might
make
> sense to provide a default.
>
> As a proof of concept, I put a context resolver in wink-common at
>
> org.apache.wink.common.contexts.resolver.JAXBContextResolver
>
> And added the following to
> wink-common/src/main/resources/META-INF/core/wink-providers
>
> # Context Resolvers
> org.apache.wink.common.contexts.resolver.JAXBContextResolver
>
> I poked around in the debugger a bit just to see how everything got
loaded
> up. It looked to me like the context resolvers were loaded in the
correct
> order. My sample also picked up the right provider with this context
> resolver in place as well.
>
> I'd like to hear opinions on this... or if you wish, I can work on
building
> up a sample to demonstrate value. I figured I'd pose the idea here on
the
> mailing list instead of a Jira to get a sense of what we want or need.
>
> I think the value-add is that JAXB has a very standardized way of
> processing data, and it's clear when we should be working with JAXB
> objects, so an app should not necessarily be responsible for including
> their own JAXB context resolver.
>
> Any thoughts, concerns, objections?
>
> Thanks..
> mike
>
--
- Bryant Luk
