Yes, Apache did not get the access to the latest one unfortunately, only
to the early one, where one of the tests has this issue as far as I
remember. So yeah, we have the early TCK compliance only - something I'm
honestly referring to :-).
By the way, recall that if you do something like
"@Path("subresource/sub/{id}")" then a subresource locator wins - which
is really not right, meaning that it wins in this case, but loses in the
other case...
Cheers, Sergey
On 18/03/14 16:47, Bill Burke wrote:
> I guess you haven't passed the TCK yet then. :)
>
> On 3/18/2014 12:45 PM, Sergey Beryozkin wrote:
>> The fact a sub-resource is discarded per the spec in this case is indeed
>> a major spec issue, can really affect the spec quality as seen by the
>> users. FYI, I did not bother updating CXF to get subresources ignored in
>> the case like the one below...
>>
>> Thanks, Sergey
>>
>>
>> On 18/03/14 16:38, Bill Burke wrote:
>>> Yet another user complaining about the JAX-RS matching algorithm...
>>>
>>> Enjoy! More to follow :)
>>>
>>>
>>> -------- Original Message --------
>>> Subject: [Resteasy-developers] Upgrading from 2.3.3 to 3.0.6
>>> Date: Tue, 18 Mar 2014 11:34:30 -0400
>>> From: XXXXXX
>>> To: resteasy-developers_at_lists.sourceforge.net
>>>
>>>
>>> Hello,
>>>
>>> We're attempting to move from 2.3.3 (final) to 3.0.6 (final) and
>>> experiencing a few issues. One is an apparent change to the matching
>>> algorithm - for example, we have...
>>>
>>> @Path("path")
>>> public interface Resource
>>> {
>>> @Path("subresource/{id}")
>>> SubResource get(@PathParam("id") String id);
>>>
>>> @PUT
>>> @Path("subresource/{id}")
>>> String open(@PathParam("id") String id);
>>> }
>>>
>>> public interface SubResource
>>> {
>>> @DELETE
>>> String close();
>>> }
>>>
>>> Previously that would work fine. Now we get an exception / 405 code
>>> because it finds the PUT (only/instead). If I comment out the PUT, then
>>> the DELETE gets called fine. What is the best way to address this?
>>>
>>>
>>
>>
>