On Jan 31, 2013, at 6:29 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> 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 ?
Yes, exactly.
>
>> 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 ?
I thought the algorithm above is also clear on that. For a mapped exception response, ALL applicable response filters are invoked (not only "remaining ones"). So, both, A and B are invoked.
FWIW, throwing an exception from a filter is IMO not the programming model we should optimize for. Such exceptions should mostly indicate that there is a problem with the filter implementation as such.
HTH,
Marek
>
> 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
>>
>
>