[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:50:55 +0000

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

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