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.
If in the above case RootContext returns RootSub then no Root is
visible, if it is Root then there's some possible confusion caused by
the fact that getResourceMethod will return getResponse() which is not
relevant to Root
Cheers, Sergey
>
> -- Santiago
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com