Bill,
I really share your disappointment, but the spec is as it is now. Best we
could do now is (a) tell people frankly that the spec was not clear enough
so we actually have 2 of 3 products being non-compliant (but intuitive) and
1 product being compliant (but non-intuitive) and then (b) add to JAX-RS 3.0
the ability for an application to provide a custom matcher
("MatcherProvider").
-Markus
-----Original Message-----
From: Bill Burke [mailto:bburke_at_redhat.com]
Sent: Montag, 12. Oktober 2015 23:49
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: @Path with regular expression overrides other @Path's with the
same URI
Keep falling back on that backward compatibility argument... Its just well,
shortsighted... There's nothing more frustrating than something that
doesn't work the way you would think it should work for simple cases that
are not uncommon. Would you tout backward compatibility if there was a
security hole? NO...Time to put usability holes on par.
On 10/12/2015 9:31 AM, 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
>>>>>
>>>>
>>>
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com