users@jax-rs-spec.java.net

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

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Thu, 20 Mar 2014 14:47:12 -0400

Hi Sergey,

I think this is something we ought to capture in a JIRA for future discussion, if we haven't already. We are always open to suggestions on how to improve JAX-RS, but we need to this carefully and ensuring that we never break backwards compatibility.

Thanks.

-- Santiago

On Mar 20, 2014, at 8:50 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:

> Hi Santiago
> On 19/03/14 12:31, Santiago Pericas-Geertsen wrote:
>> 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.
>
> First of all let me clarify: I'm generally happy enough with the matching algorithm, I think it is nearly as flexible as it can be in scope of selecting Java classes and resource methods, but it has a single bug which upsets me.
>
> The reason I call it a bug is that in CXF we support the below case without any 'salto mortale' affecting the effectiveness or the technical stability of the algorithm.
>
> I honestly do not think that 1.0 EG specifically talked about this specific issue, otherwise we'd not end up with two implementations but RI supporting the positive matching outcome in the cases similar to the one below.
>
> IMHO this particular scenario was not taken into the consideration, it was either an over-sight or the case of the implementation specifics leaking into the spec: but it is not really important whether it was the case or not, as I said I support/respect the work gone into the algorithm design, but IMHO it needs to support this case correctly.
>
>>
>> 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.
>>
> So this is how CXF implements it:
>
> 1. if we have a path match on the subresource locator then this locator is added to the list of the candidates (no method/media types check) and is not dropped immediately
>
> The other resource methods matching the path, HTTP method, Produces/Consumes request are also added.
>
> 2. when comparing the resource method with a subresource locator, the resource method always wins. If we have two subresource locators then the usual path comparison is done but this is orthoginal to the actual issue.
>
> 3. Thus, subresource locator wins *only* if no matching resource methods on the current service class are available. *Never* the subresource locator is checked in advance.
>
> I think you can see how easy the fix is, though I'm not sure right now how this can be formalized in the text properly.
>
> As far as the backward compatibility is concerned:
> - RI does not support this case therefore no RI users can be affected by not dropping the subresource locators immediately, when we have a case of a parent resource exposing a subresource.
>
> - OPTIONS. As far as I recall this was the only practical concern Marek expressed. For example, what happens when in the below case one does
>
> OPTIONS path/subresource/1.
>
> I think this is an easy fix too and it is actually not related to this issue really. The spec has to write down that when a subresource end up processing OPTIONS and it has no the dedicated handler then all the methods on this subresource and previously matched roots have to be listed. It is a common sense and is not related to the actual issue we discuss right now but it will also ensure the backward compatibility in this case
>
> Thanks, Sergey
>
>
>> -- 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
>>>>>
>>>>>
>>>>
>>>
>>>