users@jax-rs-spec.java.net

[jax-rs-spec users] Re: SubResource method vs SubResource locator clarification

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Mon, 27 Apr 2015 14:57:09 +0100

But either way, I think it is correct to conclude that if M set is non
empty then a matching subresource locator always get discarded...

To be honest - I'm fine with it this stage as I don't expect the spec
doing any more modifications. Just would like to get one final
confirmation because I was under a strong impression that in Root2 case,
getSub() was winning, but I'm fine with drawing a line here and just
accepting that a non-empty M set always gets a preference when both
resource methods and a sub-resource method become candidates

Sergey

On 27/04/15 14:48, Sergey Beryozkin wrote:
> Hi Santiago
> On 27/04/15 14:21, Santiago Pericas-Geertsen wrote:
>> Hi Sergey,
>>
>>> POST /root/1
>>>
>>> @Path("root")
>>> public class Root1 {
>>> @GET @Path("1") Response get() {...}
>>> @Path("{id}") Root1Sub getSub() {...}
>>> }
>>>
>>> getSub() is discarded, we have 405.
>>>
>>> but with
>>>
>>> @Path("root")
>>> public class Root2 {
>>> @GET @Path("{id}") Response get() {...}
>>> @Path("1") Root2Sub getSub() {...}
>>> }
>>>
>>> getSub() is selected and is given a chance to check if it has a POST
>>> handler.
>>>
>>> I've just re-read 3.7.2.2, (g) and (h) in particular, and it appears
>>> that a sub-resource locator never gets a chance if there's a path
>>> match on one of the current resource's methods such as "get()".
>>
>> Why? Are you saying that in (g) the set M is not empty? I'm assuming
>> you're talking about your second example above.
>>
> Yes, after Root2 is selected, we have "1" left, and that matches get()
> with a Path("{id}"). Right ?
>
> Cheers, Sergey
>
>
>
>
>
>
>> -- Santiago
>>
>
>