Re: JSR311: Re: ContextResolver removal

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Mon, 09 Jun 2008 15:46:32 -0400

On Jun 9, 2008, at 12:34 PM, Bill Burke wrote:
>> I have found ContextResolver<JAXBContext> to be a very useful way
>> to configure JAXB related entity providers without the developer
>> having to rely on:
>> 1) the specifics of JAXB entity providers;
> Untrue. You have to know that Jersey providers use ContextResolver
> to obtain very specific configuration information.
That's a good point, the spec doesn't currently require the standard
JAXB entity provider to use an application-supplied
ContextProvider<JAXBContext>. This was an oversight that needs to be
fixed if we retain the ContextProvider interface.

>> I have not looked but my guess is the same mechanism could be
>> useful for XMLBeans or JiBX related configuration as well.
> Sure, they could, but I'm also sure that @Providers will need other
> types of injectable configurable information. We will end up
> standardizing specific ad-hoc configuration mechanisms for those
> different use cases too? Like for instance, maybe I want to inject
> contextual information based on an annotation value. Maybe I want
> to inject contextual information based on a specific header. Maybe
> I want my org.w3c.Document @Provider to configurably turn off XML
> validation based on schema type. Maybe I want a JAXB provider that
> caches based on ETag and CacheControl settings and I want runtime
> control over that cache. I hope you see what I'm getting at now.
> Again, I believe Web Beans, Spring, or Guice is a better solution to
> fill in these gaps here.
The main use-case for this interface is JAXBContext customization and
this is driven by the inclusion of a standard JAXB entity provider. If
we drop ContextResolver<T> then I think we still need some standard
way for an application to provide a customized JAXBContext and for an
entity provider to access it. Agreed ?


Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.