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
>
>> Why ? To get that @HEAD to @GET mapping working ? That is the case 1 -
>> the only one in fact. And I would like to ask you to come up with at
>> least one more example proving where the current as you say 'fixed'
>> algorithm can not be adapted as Bill and myself suggest (i.e - not to
>> lose Locators if no actual resource methods meeting HTTP verb + Media
>> Type requirements exist). I hope you will accept that no case number 2
>> exists.
>>
>
> At this point I just want the TCK fixed and/or spec amended so I can
> pass it and move onto other things.
>
I know :-)
Sergey
>