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
