Sergey,
so what is the conclusion now? CXF is broken and you will fix it?
-Markus
-----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
>>>>>