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