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

[jsr339-experts] Re: [jax-rs-spec users] Re: [Resteasy-developers] Upgrading from 2.3.3 to 3.0.6

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Wed, 19 Mar 2014 08:31:08 -0400

Hi Sergey,

> The fact the algorithm was written the way it was does not imply 'it works as designed' in this case. It is a bug.

 I don't understand your point here. The JAX-RS 1.0 EG agreed on a particular type of algorithm that they thought struck a nice balance between coverage and complexity (including no backtracking). You may or may not agree with the original design, but the algorithm is sound and the fact that it doesn't cover some cases does not make it "bug", just a different design.

 The problem is that the general case can only be handled with backtracking, something several experts were opposed to doing. Perhaps backtracking could be avoided with "lookaheads" but then the question becomes how many do you do? Regardless, this would be a fixed number, so it will always be possible to find an example that will not be covered.
 
> I believe this particular case was simply not reviewed, which is all right, but ignoring the obvious problem is not the right way either IMHO.
>
> We have a case where a matching locator is discarded despite the fact the other matching candidates have non-matching HTTP methods.
>
> IMHO this needs to be fixed. The fix is cheap and requires no advanced checking of the locators. The edge case Marek referred during the last discussion on this issue to do with HEAD or OPTIONS can be carefully treated too.
> By the way, I'd like to initiate a vote regarding this issue but perhaps this can be postponed till 3.0. 3.0 would be Ok for me.

 As I said above, the difficulty here is where to draw the line between what it is and what it isn't covered by the algorithm. I suggest that you take the existing algorithm as it in the spec, and propose modifications to it in such a way that it remains sound (backward compatible) with the original. If that could be done, without significantly increasing complexity, I do not see why we couldn't improve on the original design.

-- Santiago

> On 18/03/14 17:24, Santiago Pericas-Geertsen wrote:
>> Bill,
>>
>> This hasn't changed in 2.0, right? Isn't this because you implemented a slightly different matching algorithm in 1.0?
>>
>> -- Santiago
>>
>> On Mar 18, 2014, at 12:38 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>> Yet another user complaining about the JAX-RS matching algorithm...
>>>
>>> Enjoy! More to follow :)
>>>
>>>
>>> -------- Original Message --------
>>> Subject: [Resteasy-developers] Upgrading from 2.3.3 to 3.0.6
>>> Date: Tue, 18 Mar 2014 11:34:30 -0400
>>> From: XXXXXX
>>> To: resteasy-developers_at_lists.sourceforge.net
>>>
>>>
>>> Hello,
>>>
>>> We're attempting to move from 2.3.3 (final) to 3.0.6 (final) and
>>> experiencing a few issues. One is an apparent change to the matching
>>> algorithm - for example, we have...
>>>
>>> @Path("path")
>>> public interface Resource
>>> {
>>> @Path("subresource/{id}")
>>> SubResource get(@PathParam("id") String id);
>>>
>>> @PUT
>>> @Path("subresource/{id}")
>>> String open(@PathParam("id") String id);
>>> }
>>>
>>> public interface SubResource
>>> {
>>> @DELETE
>>> String close();
>>> }
>>>
>>> Previously that would work fine. Now we get an exception / 405 code
>>> because it finds the PUT (only/instead). If I comment out the PUT, then
>>> the DELETE gets called fine. What is the best way to address this?
>>>
>>>
>>> --
>>> 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