jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [Resteasy-developers] Upgrading from 2.3.3 to 3.0.6

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Tue, 18 Mar 2014 21:54:10 +0000

Hi Santiago

The fact the algorithm was written the way it was does not imply 'it
works as designed' in this case. It is a bug. I believe this particular
case was simply not reviewed, which is all right, but ignoring the
obvious problem is not the right way either IMHO.

We have a case where a matching locator is discarded despite the fact
the other matching candidates have non-matching HTTP methods.

IMHO this needs to be fixed. The fix is cheap and requires no advanced
checking of the locators. The edge case Marek referred during the last
discussion on this issue to do with HEAD or OPTIONS can be carefully
treated too.
By the way, I'd like to initiate a vote regarding this issue but
perhaps this can be postponed till 3.0. 3.0 would be Ok for me.

Thanks, Sergey

On 18/03/14 17:24, Santiago Pericas-Geertsen wrote:
> Bill,
>
> This hasn't changed in 2.0, right? Isn't this because you implemented a slightly different matching algorithm in 1.0?
>
> -- Santiago
>
> On Mar 18, 2014, at 12:38 PM, Bill Burke <bburke_at_redhat.com> 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?
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>>
>


-- 
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com