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/Austi n/i...@ibmus To [email protected] 07/08/2009 05:12 cc PM Subject default JAXB context resolver? Please respond to wink-...@incubato r.apache.org 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
