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

From: Santiago Pericasgeertsen <>
Date: Mon, 12 Oct 2015 14:22:40 -0400

> 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