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

From: Markus KARG <>
Date: Mon, 12 Oct 2015 19:03:42 +0200


so what is the conclusion now? CXF is broken and you will fix it?


-----Original Message-----
From: Sergey Beryozkin []
Sent: Montag, 12. Oktober 2015 17:26
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...

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