I checked the spec text and I think we should clarify this. But first we should agree on the general processing flow. Here's the my original idea about how it should work in various scenarios:
Definitions:
pre-matching request filters
request filters annotated with @PreMatching, container-only
post-matching/bound request filters
global request filters (unbound) as well as any req. filters bound to the matched method, container-only
pre-matching response filters
response filters annotated with @PreMatching, container-only
post-matching/bound response filters
global response filters (unbound) as well as any response filters bound to the matched method, container-only
Scenarios:
S1. Container, Basic:
pre-matching request filters ->
post-matching/bound request filters ->
resource method
post-matching/bound response filters <-
pre-matching response filters <-
S2. Container, Abort in post-matching req. filter:
pre-matching request filters ->
post-matching/bound request filters ->
abort
post-matching/bound response filters <-
pre-matching response filters <-
S3. Container, Abort in pre-matching req. filter:
pre-matching request filters ->
abort
pre-matching response filters <-
S4. Container, Exception in method:
pre-matching request filters ->
post-matching/bound request filters ->
resource method, throws exception
exception mappers
post-matching/bound response filters <-
pre-matching response filters <-
S5. Container, Exception in post-matching req filter:
pre-matching request filters ->
post-matching/bound request filters, throws exception ->
exception mappers
post-matching/bound response filters <-
pre-matching response filters <-
S6. Container, Exception in pre-matching req filter:
pre-matching request filters, throws exception ->
exception mappers
pre-matching response filters <-
S7. Container, Exception in post-matching resp. filter:
S7.1. Repeated filter execution successful
pre-matching request filters ->
post-matching/bound request filters ->
resource method
post-matching/bound response filters, throws exception <-
exception mappers
post-matching/bound response filters <-
pre-matching response filters <-
S7.2. Repeated filter execution failed
pre-matching request filters ->
post-matching/bound request filters ->
resource method
post-matching/bound response filters, throws exception <-
exception mappers
post-matching/bound response filters, throws exception <-
exception mappers
pre-matching response filters <-
S8. Container, Exception in pre-matching resp. filter:
S8.1. Repeated filter execution successful
pre-matching request filters ->
post-matching/bound request filters ->
resource method
post-matching/bound response filters <-
pre-matching response filters, throws exception <-
exception mappers
pre-matching response filters <-
S8.2. Repeated filter execution failed
pre-matching request filters ->
post-matching/bound request filters ->
resource method
post-matching/bound response filters <-
pre-matching response filters, throws exception <-
exception mappers
pre-matching response filters, throws exception <-
<- exception mappers
Alternatively, we could simplify the model above by not trying to invoke the response filters once again after an exception, IOW:
S7A. Container, Exception in post-matching resp. filter:
pre-matching request filters ->
post-matching/bound request filters ->
resource method
post-matching/bound response filters, throws exception <-
exception mappers
pre-matching response filters <-
S8A. Container, Exception in pre-matching resp. filter:
pre-matching request filters ->
post-matching/bound request filters ->
resource method
post-matching/bound response filters <-
pre-matching response filters, throws exception <-
<- exception mappers
We could even decide to not run response filters at all after an exception is mapped, but that would be wrong IMO as JAX-RS users can already leverage the EM mechanism to produce responses.
Additionally, in all of the scenarios, if an exception is raised in the exception mappers or is not mapped, then container would return 500.
Also note that these scenarios can be combined into more complicated ones. E.g. (using S1-S8):
pre-matching request filters ->
post-matching/bound request filters ->
resource method, throws exception (S4)
exception mappers
post-matching/bound response filters, throws exception <- (S7.2)
exception mappers
post-matching/bound response filters, throws exception <-
exception mappers
pre-matching response filters <- (S8.1)
exception mappers
pre-matching response filters, throws exception <-
As for the client side, the things are just a bit easier as we can simply remove one layer of request and response filters from the scenarios.
Thoughts?
Marek
On Aug 14, 2012, at 7:57 PM, Bill Burke <bburke_at_redhat.com> wrote:
> Apologies,
>
> Do we filter after ExceptionMapper?
>
> On 8/14/2012 9:42 AM, Marek Potociar wrote:
>> Not sure what I mean. Method interceptors are off-scope for this release.
>>
>> Marek
>>
>> On Aug 14, 2012, at 12:16 AM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>> Something we'll have to define.
>>>
>>>
>>> -------- Original Message --------
>>> Subject: [Resteasy-users] PostProcessInterceptors not invoked for
>>> responses created by ExceptionMappers
>>> Date: Mon, 13 Aug 2012 15:14:31 -0500
>>> From: Allen Gilbert <allen.gilbert_at_doane.edu>
>>> To: resteasy-users_at_lists.sourceforge.net
>>>
>>>
>>>
>>> I have a PostProcessInterceptor that I'd like to be invoked for every
>>> response, but I've discovered that if one of my ExceptionMappers creates
>>> a response, the PostProcessInterceptor is not invoked. I did some
>>> searching and found someone else who ran into the same problem:
>>> https://community.jboss.org/thread/201677
>>>
>>> As far as I know, the current JAX-RS spec doesn't speak to this, as it
>>> doesn't define interceptors. Is this interaction between
>>> ExceptionMappers and PostProcessInterceptors working as designed, or can
>>> RESTEasy be updated to invoke PostProcessInterceptors for
>>> ExceptionMapper responses?
>>>
>>> Thanks!
>>>
>>> -Allen
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com