Details
-
Bug
-
Resolution: Done
-
Major
-
2.3.1
-
None
-
None
Description
Create an exception called "MyCustomException" like this:
public class MyCustomException extends RuntimeException { public MyCustomException(final String message) { super(message); } }
Declare a abstract exception mapper like this:
public abstract class AbstractExceptionMapper<E extends Throwable> implements ExceptionMapper<E> { @Override public Response toResponse(final E exception) { final ResponseBuilder builder = Response.ok(); handleError(builder, exception); return builder.build(); } protected abstract void handleError(final ResponseBuilder builder, E e); }
Create two implementations of this class:
@Provider public class DefaultExceptionMapper extends AbstractExceptionMapper<RuntimeException> { @Override protected void handleError(final ResponseBuilder builder, final RuntimeException e) { System.out.println("Default!"); } }
@Provider public class MyCustomExceptionMapper extends AbstractExceptionMapper<MyCustomException> { @Override protected void handleError(final ResponseBuilder builder, final MyCustomException e) { System.out.println("Custom!"); } }
Add both classes as providers in RESTEasy and throw a MyCustomException from a service method.
RESTEasy will choose the DefaultException mapper to handle the error. This is not correct behaviour.
The problem lies in how RESTEasy looks for the generic type associated with the ExceptionMapper interface. I've located this problem to the getActualTypeArgumentsOfAnInterface()-method of the org.jboss.resteasy.util.Types class.