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

From: Markus KARG <>
Date: Wed, 14 Oct 2015 22:41:31 +0200


I understand your arguments, but for users (and for TCK) compliance is a true/false question. As an ISV I need to rely on the fact that matching works exactly the same on all implementations (at least as long the spec does not provide a means for an application to provide its own matching algorithm).

So what do we tell people now? They wait for an answer. Are CXF/RestEasy definitively non-compliant or not?


-----Original Message-----
From: Sergey Beryozkin []
Sent: Montag, 12. Oktober 2015 22:33
Subject: Re: @Path with regular expression overrides other @Path's with the same URI

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