On Aug 22, 2012, at 9:22 PM, Santiago Pericas-Geertsen <santiago.pericasgeertsen_at_Oracle.com> wrote:
>
> On Aug 22, 2012, at 11:59 AM, Bill Burke wrote:
>
>> Maybe this might simplify things?
>>
>> If exception thrown from resource method
>> - ExceptioMapper
>> - response filters and interception if there is an entity.
>>
>> If an exception thrown in response filter (or WriterInterceptor)
>> - ExceptionMapper
>> - no additional filtering or interception.
>
> How about this variation? Exception in:
>
> (1) Pre-match request filter or Response filter or Writer Interceptor
> -> Exception Mapper -> Response
>
> (2) Post-match request filter or Resource method or Reader interceptor
> -> Exception Mapper -> Response chain -> Response
Why is reader interceptor different?
> Notes:
>
> - If abortWith(Response) called in pre-match then (1)
Why should abortWith(Response) be treated differently for this case? FWIW, in Jersey we have not seen ANY use case where a response filter would require resource information. I'm not saying there are no such use cases. Yet from our experience response filters deal almost exclusively with response headers or entity. So I'd say that global response filters should be applied to abort response in all cases.
>
> - If abortWith(Response) called in post-match then (2)
>
> - Writer interceptors executed after Exception Mapper
So if executed BEFORE any exception mapping, the exception thrown from a writer interceptor and mapped to a response would still be filtered?
>
> - At most one Exception Mapper can be used per request/response (no loops)
What does that mean? E.g. in case (2), what if the second exception is thrown in the response chain? Wouldn't it get mapped to a response?
>
> - No such thing as pre-match response filter
For the reasons explained above I'd more agree with a concept of no such thing as "post-matching" global response filters. IOW, global response filters should be invoked for any response regardless of whether the request has been matched or not.
To clarify: by global I mean not name-bound and not dynamically bound. (From previous Jersey experience I would apply the same to request filters too - see my reasoning in my reply to Bill's email.)
Marek
>
> -- Santiago
>
>
>