On May 13, 2009, at 8:51 PM, Tatu Saloranta wrote:
> On Wed, May 13, 2009 at 2:28 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>> Hi Daniel,
>>
>> It is possible to process 404 responses by writing a container
>> response filter:
>> https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/jersey/com/sun/jersey/api/container/filter/package-summary.html
>>
>> That will catch all request not processed by the programmer and
>> requests
>> that are processed that return 404 responses. Since the above
>> supports a
>> larger set of cases that you stated i am not sure if that is
>> sufficient for
>> your needs.
>>
>> Currently there is no way to catch a request that did not match.
>> However, it
>> should be easier to add some state to the ContainerResponse to
>> indicate
>> whether the request was matched or not.
>>
>> It is not possible to write a resource class that is invoked if a
>> request
>> does not match, but i suppose that might be easy to support if
>> required and
>> the above does not meet your requirements.
>
> For what it's worth, I tackled with this same problem, without
> particularly clean solution (I did add what I hoped to be a
> "catch-all" resource, which caught some but not all cases).
> Response filter sounds like it'd do the trick, and if (when?) it does
> not need any changes to web app's web.xml, that'll work for me.
>
Part of the issue is that filters need to be declared in a specific
order so it is not possible to use @Provider on a filter.
One solution is to use say specialization of ResourceConfig, e.g. the
one for package scanning, extend that and add the filter to the
properties in code.
I suppose in this case one wants such a filter to be added at the
start of the response filter chain. Open to suggestions on how best to
achieve this.
Paul.