jsr339-experts@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 22 May 2013 11:59:47 +0200

On May 21, 2013, at 10:09 PM, Sergey Beryozkin <sberyozkin_at_talend.com> 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
>
> GET /sub
> and
> HEAD /sub
> and
> OPTIONS /sub
>
> will be correctly and as expected delivered to Locator methods ?

I understand your point and I can see that it may be in some cases slightly confusing, but I have to put those feelings aside here. The matching algorithm is at the very core of the spec and my main goal is to make sure that this piece remains BW compatible. IOW, any new extensions that make life of developers easier are fine (such as support for multiple resources with the same path), but incompatible changes are not. The matching algorithm simply enforces certain programming model that prefers resource and sub-resource methods placed directly on the resource to methods discovered via sub-resource locators. To put it differently, if one designs a resource class with methods for a specific resource (or sub-resource), one should not try to additionally extend the set of methods using sub resource locator mechanism. If that is required, then ALL the methods must be provided using this mechanism. It's a restriction, and again, I understand that it may in certain cases come out as confusing, but I can see how it makes the code more readable OTOH.

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

To that comment I could retort that what you are fighting for is an edge case artificially crafted to demonstrate the problem. How many users in their would design their resources this way IRL?

>
> 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.
>
> I propose to fix 405 JIRA issue (in addition to 404 one which we have to fix for obvious reasons) and make a special exception for HEAD case to preserve the BC in this specific (and not to be recommended to any user) case, i.e, if we have a HEAD request, no specific HEAD handler but a default GET handler - we simply say that if it is HEAD then it matches GET - and I can live with the fact that the Locator won;t be able to manage HEAD in such cases.

I propose we fix the bug in the current wording to make the algorithm truly BW compatible, then we cool down a bit :) and if we can find some real-life use cases to justify the change, we would come up with an extension for 2.1 which will be backward compatible and support this construct, e.g. by introducing a new special annotation that will force the runtime to not exclude the locators or that will make sure that @HttpMethod annotations are checked before the locators are excluded (even though as I'm writing this I already see the new problems with matching Produces/Consumes that will pop up once we would make such change, as we're just moving the issue to the next matching phase; in any case we will have to carefully think this through, this is not a good area for making hasty decisions).

Marek

>
> Sergey
>
>
>
> On 21/05/13 17:48, Marek Potociar wrote:
>>
>> On May 21, 2013, at 6:36 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>> On 5/21/2013 12:28 PM, Sergey Beryozkin wrote:
>>>> On 21/05/13 17:24, Marek Potociar wrote:
>>>>> Sergey, you are right - I failed to notice that the POST method does
>>>>> not have the same literal path value as the SRL method. I apologise.
>>>>>
>>>> No problems Marek at all, how many times I've argued my point without
>>>> reading the responses properly :-). And in this case we have a fairly
>>>> deep thread :-)
>>>>
>>>
>>> I'm lost myself...What is the conclusion? Do locators match in these situations?
>>
>> Here's my understanding:
>>
>>>
>>> Requests:
>>> GET /sub
>>
>> No. The (fixed) algorithm, compliant with JAX-RS 1.1, will match the POST method and fail in step 3.
>>
>>> OPTIONS /sub
>>
>> No. The matched POST method will cause that OPTIONS is not found in step 3 and the default OPTIONS response is provided by runtime
>>
>>> HEAD /sub
>>
>> No. The matched POST method will cause that neither HEAD nor GET is not found in step 3 and the request should fail with 405
>>
>> Marek
>>
>>>
>>> @Path("/")
>>> public class Resource {
>>>
>>> @Path("sub")
>>> @POST
>>> public void post();
>>>
>>>
>>> @Path("{ID}")
>>> public Locator locator;
>>> }
>>>
>>>
>>> class Locator {
>>>
>>> @GET get();
>>> @OPTIONS options();
>>> @HEAD head();
>>>
>>> }
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com