On 5/21/2013 6:20 PM, Sergey Beryozkin wrote:
> On 21/05/13 23:16, Bill Burke wrote:
>>
>>
>> On 5/21/2013 4:09 PM, Sergey Beryozkin wrote:
>>> And now do
>>>
>>> @Path("/")
>>> public class Resource {
>>> @Path("{sub}")
>>> @POST
>>> public void post();
>>> @Path("sub")
>>> public Locator locator;
>>> }
>>> class Locator {
>>> @GET get();
>>> @OPTIONS options();
>>> @HEAD head();
>>> }
>>>
>>>
>>> Does it even concern you at all that in the above case (and as we've all
>>> now agreed to, including yourself) that
>>>
>>
>> Where was this agreement?
>
> Well, please review the sequence of steps in the other email which
> Santiago, Marek and myself concluded were correct
>
>>
>>> GET /sub
>>> and
>>> HEAD /sub
>>> and
>>> OPTIONS /sub
>>>
>>> will be correctly and as expected delivered to Locator methods ?
>>>
>>> I'm bemused by your protecting so strongly the current algorithm which
>>> basically loses the Locator in one case and yet keeps it, in JAX-RS 1.1
>>> compliant way, in the above case ?
>>>
>>
>>
>> I don't agree that that will happen. Step 2h explicitly removes
>> locators from matching if there is any resource method that matches the
>> expression. So the locator will be ignored in both cases. Am I missing
>> something here?
>>
> Jira 404 requests a backward-incompatible change in 2.0 fixed which will
> keep the Locator in the above case, though in your example - it will
> have to be dropped unfortunately even after the issue 404 gets fixed
>
I don't agree with how you guys decided how locators were matched in
1.1. JAX-RS 1.1 Step 2(h) talks about subresource methods, not
locators. (Same as JAX-RS 2.0 except JAX-RS 2.0 adds more explicit
language).
Bill--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com