Santiago,
I'm not quite sure what exactly you like to file as an issue? The fact that CXF and RestEasy are claimed to be not compliant with the spec, or the fact that the spec is counterintuitive?
-Markus
-----Original Message-----
From: Santiago Pericasgeertsen [mailto:santiago.pericasgeertsen_at_oracle.com]
Sent: Montag, 12. Oktober 2015 20:23
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: @Path with regular expression overrides other @Path's with the same URI
> 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
>>>>>>
>
>