One more comment about HEAD below,
On 20/03/14 12:50, Sergey Beryozkin 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
>
Some text can also be added with respect to HEAD, specifically, if we
only have GET on the current root and it is a HEAD request then the GET
method wins over the subresource, something like that - this will make
sure HEAD support is backward compatible in RI
Cheers, Sergey
> 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
>>>>>
>>>>>
>>>>
>>>
>>>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com