dev@jsr311.java.net

Re: JSR311: exception mapping of wrapper exceptions

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Wed, 25 Jun 2008 16:27:54 -0400

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 !

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 ?

Marc.

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