On 31/01/13 16:57, Marek Potociar wrote:
> 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
>
What are resource-bound filters, is it:
@SomeName
class MyFilter...
@SomeName
@Path("/root")
public class RootResource {
}
Effectively MyFilter applies to all RootResource methods ?
> 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
>
I think it basically says that in Bill's (2) case all response filters
are executed,
What about his case 3 though, I think it is UC6, UC7 points, still not
clear what if the mapped response has to run through remaining filters
or not, for example,
A->B, A throws the exception, is B still given a chance to handle the
mapped response ?
Thanks, Sergey
> HTH,
> Marek
>
>
> On Jan 30, 2013, at 4:29 PM, Bill Burke <bburke_at_redhat.com
> <mailto: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
>