Sergey,
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?
-Markus
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
Sent: Montag, 12. Oktober 2015 22:33
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
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
>>>>>>>
>>