users@jax-rs-spec.java.net

[jax-rs-spec users] Re: _at_Logged deep binding

From: Alex Rojkov <alex_at_caucho.com>
Date: Wed, 6 Feb 2013 13:50:49 -0800

>>>>>>>>> IMO it should.
>>>>>>>>
>>>>>>>> Thanks. I am adding conditional return to MyResourceClass#hello.
>>>>>>>>
>>>>>>>> MyResourceClass#hello may return any implementation of Foo. Some implementations may not be annotated with @Logged.
>>>>>>>>
>>>>>>>> Can you explain how a jaxrs implementation can determine that LogginFilter should be invoked?
>>>>>>>
>>>>>>> By introspecting the Java type of the returned sub-resource instance. Since this is a potentially processing-intensive operation, the implementations may consider caching the introspection results for future use.
>>>>>>
>>>>>> I see. That means filters can be invoked between resources / sub resource method invocations. Appendix C suggests that filters are invoked before any resource method invocations.
>>>>>
>>>>> Not sure what you mean by "filters can be invoked between resources / sub resource method invocations". Note that subresource locators are part of JAX-RS request-to-resource method matching facility and following is the only possible scenario for any matched request:
>>>>>
>>>>> request -> [subresource-locator [-> ... -> subresource-locator] -> ] resource method
>>>>>
>>>>> The above demonstrates that zero or more sub-resource locators may be invoked as part of the request URI matching process. If we add filters into picture, we get:
>>>>>
>>>>> request -> pre-match filters -> [subresource-locator [-> ... -> subresource-locator] -> ] post-match global & name-bound filters -> resource method
>>>>>
>>>>> The name-bound filters are selected based on the resource method and it's owner instance that was matched to ultimately handle the request (with or without help of sub-resource locators).
>>>>>
>>>>>> IMO, the spec needs to be more clear about Filter contract.
>>>>>
>>>>> It would be good if you could come up with concrete suggestions for improvements. It's hard to see what does "more clear" mean in general.
>>>>
>>>> Sure. How about adding the below to clarify:
>>>>
>>>> post-match global filters are invoked before any of the root-resource methods are called.
>>>> name bound filters are invoked before a bound method is called.
>>>
>>> Have you seen the Appnedix C in the spec? The processing pipeline diagram is there.
>>
>> Yes, I have. It suggests that ContainerRequest chain is completed before Method Invocation. It means to me that ContainerRequest chain is completed before the vert first method invocation (method on a root-resource).
>
> No, the Request Matching box refers to the matching algorithm, the outcome of which is *the* method resource that is going to serve the request, excluding any intermediaries. The Method Invocation box refers to that method serving the request. All the intermediate steps (resource locators, etc.) part of the Request Matching box --please refer to the algorithm in 3.7.2.

OK. Thanks. This helps. I got stuck in Filter idiom for Servlets.

Alex

> -- Santiago