Hi Bill,
I'm forwarding my recent reply to a similar question we received from TCK team:
Global and globally name-bound filters and interceptors should be invoked for all responses. Resource and method name-bound interceptors should be invoked only for responses originated from the bound resource or resource method.
I.e. if we define 2 groups of filters and interceptors based on their binding:
G1: Global and globally name-bound (i.e. name-bound to the Application sub-class) response filters and interceptors
- IMO the user intention with these is clearly to invoke them for ALL responses
G2: Resource and method name-bound response filters and interceptors
- IMO the user intention with these is to invoke them only for responses originated from a particular resource or method
With the groups defined above, here's what I think it should work (Santiago, please correct me if you think otherwise):
UC1: Response returned from pre-matching filter:
- G1 gets invoked
UC2: Response produced by an ExceptionMapper from an exception that originated in a pre-matching filter:
- G1 gets invoked
UC3: Response returned from post-matching filter:
- G2 + G1 gets invoked
UC4: Response returned from matched resource method:
- G2 + G1 gets invoked
UC5: Response produced by an ExceptionMapper from an exception that originated in a matched resource method:
- G2 + G1 gets invoked
UC6: Response produced by an ExceptionMapper from an exception that originated in a response filter or interceptor processing a response to a matched request:
- G2 + G1 gets invoked
UC7: Response produced by an ExceptionMapper from an exception that originated in a response filter or interceptor processing a response to an unmatched request:
- G1 gets invoked
Additionally, there is a condition in the spec that prevents infinite loops for UC6 and UC7 (see 2nd paragraph in section 6.7 of the spec). So, to sum-up, here's the conceptual algorithm I have in mind:
start request processing
store G1 response filters and interceptors into the request context
try {
invoke pre-matching request filters
match request
if (request matched) {
store G2 response filters and interceptors into the request context
invoke global and bound post-matching request filters
invoke resource method
}
invoke all response filters stored to the request context
} catch (Exception ex) {
try {
map exception to response
invoke all response filters stored to the request context
} catch (Exception ex) {
propagate exception to the hosting container
}
}
exit request processing
HTH,
Marek
On Jan 30, 2013, at 4:29 PM, Bill Burke <bburke_at_redhat.com> wrote:
> The section on filters and exception handling is unclear.
>
> if an exception is thrown from a resource method:
>
> 1. An exception mapper is found
> 2. bound and global filters are executed on the response
>
> If an exception is thrown from a request filter:
>
> 1. An exception mapper is found and executed
> 2. response filters are executed. BOund response filters only executed if this is not prematch
>
> If an exception is thrown from a response filter:
>
> 1. An exception maper is found and executed
> 2. ??? I assume no response filters are then executed?
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com