ContainerResponseFilter, ExceptionMapper, and order of operations

[Erin Noe-Payne <er...@gmail.com>]

Hi All,

I am setting up a restful web service.

I am using ContainerResponseFilters to perform common operations -
setting headers, wrapping json responses, and so on.

I am using ExceptionMappers to capture common types of exceptions that
will map to 404, 400, 401 and 403 errors, etc, and give them
consistent error messaging.

The issue I am encountering is that errors that trigger an exception
mapper do not pull the response out of the filter chain. That is, an
error that maps to a 404 response still ends up going through filters
to set headers or wrap it as a json response - operations that don't
make sense in the context of a 404.  How can I control the order in
which filters are executed or guarantee that error conditions break
out of the standard filter chain?

Thanks,
Erin

Re: ContainerResponseFilter, ExceptionMapper, and order of operations

[Sergey Beryozkin <sb...@gmail.com>]

Hi
On 05/08/13 17:47, Erin Noe-Payne wrote:
> Hi All,
>
> I am setting up a restful web service.
>
> I am using ContainerResponseFilters to perform common operations -
> setting headers, wrapping json responses, and so on.
>
> I am using ExceptionMappers to capture common types of exceptions that
> will map to 404, 400, 401 and 403 errors, etc, and give them
> consistent error messaging.
>
> The issue I am encountering is that errors that trigger an exception
> mapper do not pull the response out of the filter chain. That is, an
> error that maps to a 404 response still ends up going through filters
> to set headers or wrap it as a json response - operations that don't
> make sense in the context of a 404.  How can I control the order in
> which filters are executed or guarantee that error conditions break
> out of the standard filter chain?

If a given exception does not escape and is mapped to Response then it 
is still routed through a filter chain, that is true.

I guess one option is to to have a base filter implementation which will 
check ContainerResponseContext.getStatus() and if it is >= 400 then the 
concrete extensions will skip their processing.

Another possibility is to push some of the processing to 
WriterInterceptor chain, this will run if a response entity is not null, 
so if the exceptional Response has no entity then it won't be affected 
by WriterInterceptors...

HTH
Sergey

>
> Thanks,
> Erin
>