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

From: Sergey Beryozkin <>
Date: Thu, 20 Mar 2014 12:56:42 +0000

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

Sergey Beryozkin
Talend Community Coders