Hi Chris,
There is currently no way to isolate certain exceptions from being
mapped if an exception mapper matches a super class of the exception.
Jersey has a feature that if you throw a MappableContainerException
[1] from an ExceptionMapper then it passes through and the cause of
the MappableContainerException gets added as the cause of a
ServletException. I am not sure if that will meet your requirements or
not. I could refine this so that if the cause is a RuntimeException it
is thrown directly rather than being wrapped in ServletException.
Or it might be possible to add a feature to declare unmapped exceptions.
If the ServletException does not work i guess you could add a hack
with a another filter that unwraps the cause and rethrows on certain
exceptions.
Paul.
[1]
https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/container/MappableContainerException.html
On Sep 1, 2010, at 7:05 PM, Camel Christophe wrote:
> Hello everybody,
>
> I’m using Spring security on top of a REST web application that uses
> Jersey. This application declares a filter
> “org.springframework.security.ui.ExceptionTranslationFilter” that
> handles org.springframework.security.AccessDeniedException in the
> filter chain.
>
> From the Jersey side, I also use a translator
> “javax.ws.rs.ext.ExceptionMapper” that converts any caught
> exceptions into appropriate http responses. Unfortunately, with this
> filter the AccessDenied is also caught and thus never propagated to
> the spring security filter.
>
> So, what is the best way of dealing with that ? Rethrow the
> exception within the toResponse() method of the ExceptionMapper
> implementation doesn’t work ! Jersey considers this like a severe
> error and reports it but does not propagate the exception to the
> caller.
>
> Thanks for any help.
>
> Chris.