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: Santiago Pericasgeertsen <santiago.pericasgeertsen_at_oracle.com>
Date: Mon, 12 Oct 2015 14:22:40 -0400

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