[jax-rs-spec users] Re: _at_Path with regular expression overrides other @Path's with the same URI

From: Sergey Beryozkin <>
Date: Mon, 12 Oct 2015 21:32:56 +0100

Hi Santiago

I was thinking on the way home, I thought the sentence where the 'M' set
is built from Rmatch = R(Td) is a bit strict.
I recall the explicit regular expressions were added at the last moment
in 1.0,
the current text covers a situation with same verbs OK (in that Jersey
issue I thought there were two GETs where I'd indeed expect
the method with an explicit reg expression win)...

Rmatch = R(Td) condition blocks a GET method from being included in M
(referring to that example).
I suspect replacing a '=' symbol with another one implying Rmatch is
equal or equivalent to R(Td).
I suspect I might've got confused with my analysis above but I open an issue

Markus, I'm not sure the fact CXF/Reasteasy would not select DELETE
makes either implementation broken :-).
My opinion the spec text is far from being perfect in this specific case
which I agree makes CXF/RestEasy is not compliant here but perhaps in
this case the spec text can be optimized before a new TCK test is added :-).

Thanks, Sergey

On 12/10/15 19:22, Santiago Pericasgeertsen wrote:
>> On Oct 12, 2015, at 1:03 PM, Markus KARG <> wrote:
>> Sergey,
>> so what is the conclusion now? CXF is broken and you will fix it?
> Let’s file it as an issue and review it later. I had a quick look at the algorithm and, frankly, it is not as clear as I hoped so but I don’t have the cycles to look at it deeper at this point.
> — Santiago
>> -----Original Message-----
>> From: Sergey Beryozkin []
>> Sent: Montag, 12. Oktober 2015 17:26
>> To:
>> Subject: Re: @Path with regular expression overrides other @Path's with the
>> same URI
>> Hi Santiago
>> That long discussion we last had, that was related to a case where a
>> matching subresource locator
>> was discarded, even though it was having a matching method, as opposed
>> to the current resource class.
>> It still 'hurts' whenever I think about it.
>> But in this case it is different, no backtracking of any sort is even
>> needed here - it is so simple...
>> So we are at "Sort E using the number of literal characters
>> in each member as the primary key (descending
>> order), the number of capturing groups as a secondary key (descending
>> order), the number of
>> capturing groups with non-default regular expressions (i.e. not
>> '([^/]+?)') as the tertiary key
>> (descending order)..."
>> Then yeah, DELETE is supposed to be selected. This is so sad. The only
>> consolation, regular expressions are not that popular...
>> Sergey
>> On 12/10/15 14:31, Santiago Pericasgeertsen wrote:
>>> All,
>>> First, obviously I agree the result is counter-intuitive. Second, we
>> have had this this discussion many in the times in the past ;), and
>> basically the same algorithm since JAX-RS 1.0 AFAIK. Third, the algorithm
>> does not backtrack or look ahead, and thus makes a decision first on Path
>> and then on method resulting in the observed behavior -because it discarded
>> potential matches too soon.
>>> If an implementation behaves differently, it is because it is
>> implementing a different algorithm from the one in the spec. Ideally we
>> should change the algorithm, but unfortunately it is not a backward
>> compatible change.
>>> - Santiago
>>>> On Oct 12, 2015, at 9:08 AM, Sergey Beryozkin <>
>> wrote:
>>>> Oh, that is actually completely broken, I agree, I thought there were two
>> GET methods there, my fault.
>>>> I honestly can not see how that can be resolved as works as expected...
>>>> Sergey
>>>> On 12/10/15 14:00, Bill Burke wrote:
>>>>> If this is true, then the matching algorithm is showing yet again, how
>> effed up it is. The @Get method in the example should always resolve. It
>> makes sense intuitively. In Resteasy if the @Delete path resolved first,
>> but the methods didn't match, we would "backtrack" and try the get method.
>>>>> On 10/11/2015 12:00 PM, Sergey Beryozkin wrote:
>>>>>> Jersey is correct in that example - a template var with a regex wins
>>>>>> over a basic template var.
>>>>>> The spec clearly states that an expression with more literal chars
>> wins.
>>>>>> So I guess a regex expression can only win if, besides the rex-ex
>>>>>> expression itself, a given path has more literal chars, say, abc[d|e]
>>>>>> would win over abc - I think this can only happen when choosing between
>>>>>> multiple matching root resources.
>>>>>> Or it can win in that Jersey JIRA issue - a number of literal chars
>>>>>> beyond the regex is equal but the regex method wins because a template
>>>>>> var is more specific. I'll double check with CXF - I doubt it works
>> diff
>>>>>> in CXF
>>>>>> Sergey
>>>>>> On 11/10/15 08:28, Markus KARG wrote:
>>>>>>> Experts,
>>>>>>> in a discussion on the Jersey user group someone claimed that the
>>>>>>> behaviour of Jersey is different from CXF and RestEasy. As that would
>>>>>>> imply both, an inaccuracy of the TCK (it does not detect the
>>>>>>> deviation) and a violation of the specification in CXF and RestEasy
>>>>>>> (as Jersey is the RI, hence axiomatically cannot be wrong), we should
>>>>>>> quickly clarify the truth in that claim.
>>>>>>> The case is recorded in Jersey's issue tracker including source code
>>>>>>> ( and is simple to explain:
>>>>>>> *Given a resource has two methods, annotated as **_at_GET
>>>>>>> @Path(//<PathParam>/) and **_at_DELETE @Path(//<RegEx>/)*
>>>>>>> *When a client invokes **GET <RootURI>//<PathParam>/ upon that
>> resource*
>>>>>>> *Then the result is **405 Method Not Allowed*
>>>>>>> While this looks pretty odd to the average Joe (as there is a perfect
>>>>>>> match of GET and /<PathParam>/), it was claimed that this is
>>>>>>> _compliant_ to the specification (since regex have higher priority
>>>>>>> than literals, and methods are matched after URIs).
>>>>>>> It was reported that CXF and RestEasy return 200 OK instead, while the
>>>>>>> RI does return 405 Method Not Allowed.
>>>>>>> Certainly an application MUST return the same status code on ANY
>>>>>>> JAX-RS compliant implementations, so we should clarify ASAP the
>>>>>>> following questions:
>>>>>>> (1) @SpecLeads: Is the use case described above (regex beats literals)
>>>>>>> really compliant to the JAX-RS specification, and how to explain /to
>>>>>>> the average Joe/ the reasonability of ignoring the apparently perfect
>>>>>>> match?
>>>>>>> (2) @SpecLeads: Is there a bug in the TCK so it does not detect the
>>>>>>> deviation of CXF and RestEasy?
>>>>>>> (3) @Vendors: Can you please check your implementations whether they
>>>>>>> really violate the spec? Do you have plans to fix it?
>>>>>>> I think we all have a vital interest in clarifying it, as a standard
>>>>>>> makes only sense when it is reasonable and commonly accepted, so I
>>>>>>> would be glad if you could answer the above points rather soon. :-)
>>>>>>> Thanks
>>>>>>> -Markus