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