On Jun 25, 2008, at 10:27 PM, Marc Hadley wrote:
> On Jun 25, 2008, at 11:40 AM, Paul Sandoz wrote:
>>>
>>> public interface ProviderLocator {
>>>
>>> <T> MessageBodyReader<T> getMessageBodyReader(Class<T> type,
>>> Type genericType, Annotation annotations[], MediaType mediaType);
>>>
>>> <T> MessageBodyWriter<T> getMessageBodyWriter(Class<T> type,
>>> Type genericType, Annotation annotations[],MediaType mediaType);
>>>
>>> <T> ExceptionMapper<T> getExceptionMapper(Class<T> type);
>>>
>>> <T> ContextResolver<T> getContextResolver(Class<T> type);
>>>
>>> }
>>>
>>
> I think Providers is a better name.
>
> The getContextResolver method offers us an opportunity to simplify
> things. Rather than injecting a ContextResolver directly with
> @Context and requiring that the injected instance actually be a
> proxy that searches for a context resolver of the specified type
> for a particular class (did I mention it was complicated), instead
> we can define the method like this:
>
> <T> T getContext(Class<T> contextType, Class<?> objectType)
>
> So to get a JAXBContext for some JAXB bean Foo you'd write:
>
> @Context Providers p;
> JAXBContext jbc = p.getContext(JAXBContext.class, Foo.class);
>
> Much nicer !
>
From what perspective? from the client i don't think it is easier.
From that perspective i prefer the current interface.
> Also I think that, strictly speaking, getExceptionMapper should
> return ExceptionMapper<? super T> rather than ExceptionMapper<T>
> since getExceptionMapper(FooException.class) could actually return
> an ExcpetionMapper<Exception.class> if that is provider whose
> generic type is the nearest superclass of Foo. Not sure it
> particularly matters though, is it worth being explicit ?
>
I think it is worth using the type system where possible to be more
accurate.
Paul.