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.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.