users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Matching algorithm doesn't recurse back on Locators

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Fri, 17 May 2013 16:00:44 +0100

On 17/05/13 15:39, Bill Burke wrote:
>
>
> On 5/17/2013 10:35 AM, Sergey Beryozkin wrote:
>> On 17/05/13 15:32, Bill Burke wrote:
>>>
>>>
>>> On 5/17/2013 9:40 AM, Sergey Beryozkin wrote:
>>>> Hi Bill,
>>>> On 17/05/13 14:35, Sergey Beryozkin wrote:
>>>>> On 17/05/13 13:59, Bill Burke wrote:
>>>>>>
>>>>>>
>>>>>> On 5/17/2013 4:35 AM, Sergey Beryozkin wrote:
>>>>>>> Hi Bill
>>>>>>> On 17/05/13 04:41, Bill Burke wrote:
>>>>>>>> Let me give you an example:
>>>>>>>>
>>>>>>>> Given this request:
>>>>>>>>
>>>>>>>> OPTIONS /sub
>>>>>>>>
>>>>>>>> This will match:
>>>>>>>>
>>>>>>>> @Path("/")
>>>>>>>> class Resource {
>>>>>>>>
>>>>>>>> @Path("{id}")
>>>>>>>> public Locator locator() { return new Locator();}
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> class Locator {
>>>>>>>>
>>>>>>>> @OPTIONS
>>>>>>>> public String options() { return "OK"; }
>>>>>>>> }
>>>>>>>>
>>>>>>>> But this won't match:
>>>>>>>>
>>>>>>>> @Path("/")
>>>>>>>> class Resource {
>>>>>>>>
>>>>>>>> @GET
>>>>>>>> @Path("sub")
>>>>>>>> public String get() { return "OK"; }
>>>>>>>>
>>>>>>>> @Path("{id}")
>>>>>>>> public Locator locator() { return new Locator();}
>>>>>>>>
>>>>>>>> }
>> Well, both Resource methods are candidates, and those candidates which
>> are subresource locators lose to those which are not
>>
>
> The are not both candidates. Look at Step 2(h). It says goto STep 3 if
> set M is not empty. It explicitly says set M excludes sub resource
> locators.
>
> So, in the example set M is not empty and it moves to Step 3, which then
> results in an exception. Again, the TCK expects this behavior.
>
This is a breaking change in 2.0.

In 1.1 this can not happen:
https://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-360003.7.2

Bill, what test are you talking about ? I will challenge it

Santiago, comments please ? I know we now support selecting between
candidates between multiple root resources with the same path, but we
can't lose sub resource Locators like this. With 1.1 in Bill example,

OPTIONS /sub

will be absolutely properly matched to Locator.options

in 2.0 we have a non-match

Thanks, Sergey