users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
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 <markus_at_headcrashing.eu> 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 [mailto:sberyozkin_at_talend.com]
>> Sent: Montag, 12. Oktober 2015 17:26
>> To: jsr370-experts_at_jax-rs-spec.java.net
>> 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 3.7.2.2.e: "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 <sberyozkin_at_talend.com>
>> 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
>>>>>>> (https://java.net/jira/browse/JERSEY-2942) 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
>>>>>>>
>>