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.
-- Santiago