users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: What is conclusion to matching algorithm issues?

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 21 May 2013 18:16:10 -0400

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?

> 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?


> 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.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com