dev@jsr311.java.net

Re: JSR311: exception mapping of wrapper exceptions

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Wed, 25 Jun 2008 10:32:20 -0400

>>> A few Resteasy users came across a problem with exception mapping
>>> and wrapper exceptions like: EJBException, RemoteException,
>>> EJBTransactionRollbackException, hibernate BatchedException.
>>>
>>> When wrapper exceptions exist, then it sort of makes
>>> ExceptionMapper not very useful. I was thinking of two ways to
>>> solve this:
>>>
>>> #1 Rename and expand MessageBodyWorkers so that you can look up
>>> any provider
>>>
>>> #2 Define a MapCauseException. ExceptionMappers would throw this
>>> if they want JAX-RS to remap an inner exception: i.e.:
>>>
>>> Response toResponse(EJBException ex) {
>>>
>>> throw new MapCausepException(ex.getCause());
>>>
>>> }
>>>
>> I prefer #1, it seems more direct.
>>
>
> Same here, although look up of a message reader/writer provider
> requires parameters that do not apply to other types of provider.
>
> I would be inclined to create a separate interface for lookup of
> exception providers. That way things are more extensible rather then
> overloading things into one class.
>
We already have separate methods for readers and writer so I was
thinking we could just rename and add methods for the other types of
provider:

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);

}

It rounds out the functionality nicely.

Marc.

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