On 13/12/12 19:23, Santiago Pericas-Geertsen wrote:
>
> On Dec 13, 2012, at 10:10 AM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> On 13/12/12 14:40, Santiago Pericas-Geertsen wrote:
>>>
>>> On Dec 13, 2012, at 8:05 AM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>>>
>>>> Hi, consider DynanicFeature deciding which method should get applied which filters or the filter or interceptor bound to a specific subresource method working with ResourceContext.
>>>>
>>>> ResourceContext is supposed to return the name of (root) resource class and the method - but in case of subresource methods the resource class has to be the actual subresource class to make sure it matches the method returned from ResourceContext.
>>>>
>>>> IMHO it can be useful to extend ResourceContext for it to always return the current root resource class with the method getRootResourceClass() where getResourceClass() will return the 'owner' of the current resource method - it can be the same root resource class or subresource class and it will provide a better 'picture' to the code working with ResourceContext
>>>>
>>>> What do you think ?
>>>
>>> Don't really follow. How about a short example? :)
>>
>> @Path("root")
>> public Root {
>>
>> @Path("sub")
>> public RootSub getSub() {return new RootSub()}
>> }
>>
>> public RootSub {
>>
>> @GET
>> public Response getResponse() {...}
>> }
>>
>> Consider the filter bound to RootSub#getResponse.
>>
>> What will RootContext visible to such filter return in its getResourceClass() ?
>>
>> IMHO, it would be cleaner if one could see Root& RootContext as it may provide an extra context to the filter, or the dynamic feature.
>
> I'm still a bit confused by your question. Dynamic features are intended to be processed at deploy time not at run time, so there's really no way to know which locator created an instance. Apologies if I missed your point completely.
>
No worries, please forget about the dynamic feature - though the
runtimes capable of statically introspecting the subresources will know
about the subresource classes such as RootSub,
Though let me actually clarify to make it absolutely clear for me:
- Dynamic feature implementation is expected to be able to apply a
specific filter to RootSub#getResponse, is it right ?
If yes, the question is what ResourceContext#getResourceClass() and
ResourceContext#getResourceMethod() should return when DynamicFeature
impl is called in this case ?
Also lets focus on the case, a filter bound one way or the other, to
RootSub#getResponse and is expects ResourceContext injected.
What do you expect the filter seeing when calling ResourceContext
methods in this case ?
Am I totally unable to articulate what I'm actually asking :-) ?
Note - may be I'm just not understanding something,
Thanks, Sergey
> -- Santiago
>
>