On Mar 11, 2010, at 1:07 PM, Paul Sandoz wrote:
> Hi James,
>
> What if we could detect if a 404 would be returned, and if so
> proceed to the next filter in the chain?
>
> This may result in the execution of some user code e.g. execution of
> sub-resource location methods could be a definite possibility. But
> is that an issue? and for the case you present it should work really
> well.
>
> Off the top of my head there are three types of 404 we could detect:
>
> 1) No match of a URI path;
>
> 2) A query or path param conversion failure; and
>
> 3) An application return an 404, by an exception or a direct response.
>
> Maybe these cases could be configuration options?
>
Sigh, the servlet processing model is so confusing when handling error
pages, namely when you declare error pages for certain status codes.
To support this it is necessary to call ServletResponse.sendError, but
that commits the response and the next filter in the chain cannot
process that response.
In this case there has to be a compromise.
What i can do is the following when the filter is configured
appropriately:
1) if the status code is a 404 and the response is not committed then
call the next filter in the chain; and
2) configure the Jersey response to Servlet response mapping to always
use setStatus when the filter "pass
through" is configured.
that should work for any 404 returned from Jersey or the application
that has no response entity body.
Paul.