Bill, Sergey,
I would really appreciate your feedback on the bellow. (I apologize for the long email in advance.)
Marek
On Aug 15, 2012, at 11:26 AM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
> 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
>