On Jun 9, 2008, at 5:37 PM, Bill Burke wrote:
>>>
>> 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 ?
>
> I think configuration and lifecycle of both providers and resources
> is the root of the issue. Its frustrating that such a fundamental
> service (DI) is undefined in EE 5 and earlier and is meeting
> resistence in EE 6 (Web beans).
>
> Ya I agree though, whether or not you keep ContextResolver,
> mandating JAXBContext pluggability is probably a good idea.
>
One thing we could consider is to make the JAXBContext usage more
obvious. E.g. we could add a:
public interface JAXBContextResolver extends
ContextResolver<JAXBContext> {
JAXBContext getContext(Class<?> jaxbClass);
}
Alternatively we could just replace the existing ContextResolver<T>
with a JAXBContextResolver but that would remove the standardized
injection of context except for JAXB.
The advantage of either of these is that the JAXB connection becomes
much clearer and easier to discover just by scanning the Javadoc.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.