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