CXF is not following the spec then.
FYI, these particular tests pass if I loopback from Step 3a and check
the locators.
On 5/19/2013 1:50 PM, Sergey Beryozkin wrote:
> Hi Bill - FYI, CXF has no problems with the tests you've mentioned, only
> with that one we've been referring to.
>
> I'll work on response to Santiago tomorrow, have to sign off now :-)
>
> Cheers, Sergey
>
> On 19/05/13 18:44, Bill Burke wrote:
>> Well, there's a huge number of tests that fail in the TCK because of the
>> new matching algorithm if implemented as-is:
>>
>> The whole set of:
>>
>> com.sun.ts.tests.jaxrs.ee.rs.pathparam.locator and .sub tests
>>
>> See my description here if you're interested:
>>
>> https://issues.jboss.org/browse/CTS-81
>>
>> This is the only part of the specification that is total crap, IMO. The
>> algorithm is complex and leaves little room for optimization or
>> interpretation, neither the TCK nor Jersey got it right either which
>> just adds fuel to the fire. I had no problems passing the TCK prior to
>> 2.0 and now, code that is stable and 4+ years old needs to be changed.
>>
>> On 5/19/2013 9:53 AM, Santiago Pericas-Geertsen wrote:
>>> Hi Sergey,
>>>
>>> Let us focus on what the JAX-RS 1.1 spec states before we discuss
>>> the best way to handle your example. Please run the JAX-RS 1.1
>>> algorithm on your example and find the values for E, R_match and M in
>>> step 2. I'd like to understand why it works in your analysis.
>>>
>>> Thanks.
>>>
>>> -- Santiago
>>>
>>> On May 17, 2013, at 4:42 PM, Sergey Beryozkin <sberyozkin_at_talend.com>
>>> wrote:
>>>
>>>> Hi Santiago
>>>> On 17/05/13 18:15, Santiago Pericas-Geertsen wrote:
>>>>> Bill, Sergey,
>>>>>
>>>>> I can see the issue that you're reporting. However, and I don't
>>>>> have a copy of the old spec handy, I believe HTTP method filtering
>>>>> was also done in step 3 before, so why did it work before?
>>>>>
>>>>> The general idea of the algorithm has always been to avoid
>>>>> backtracking; I think it would be possible to construct a more
>>>>> involved example in which you'd need to backtrack more than one step
>>>>> to match something.
>>>>>
>>>>> Could it be that your implementation always supported backtracking
>>>>> but the TCKs didn't test that before?
>>>>>
>>>> No, we've never supported back-tracking. And as I tried to clarify,
>>>> JAX-RS 1.1 did not even require it and CXF simply followed it to the
>>>> letter.
>>>>
>>>> When we have
>>>>
>>>> @Path("/")
>>>> public class Resource {
>>>> @POST
>>>> @Path("sub")
>>>> public void post();
>>>>
>>>> @Path("{id}")
>>>> public Resource locator() {
>>>> }
>>>>
>>>> @GET
>>>> public void get();
>>>> }
>>>>
>>>> and
>>>>
>>>> GET /sub
>>>>
>>>> returning 404 is simply not the option IMHO.
>>>>
>>>> JAX-RS 1.1 adds two candidates, post() & locator() and the text
>>>> clearly makes locator() win and hence get() selected. No
>>>> backtracking, simple comparison or check: post() has a non-matching
>>>> method, it is out
>>>>
>>>> Likewise if we have
>>>>
>>>> @Path("/")
>>>> public class Resource {
>>>> @GET
>>>> @Path("{id}")
>>>> public void get();
>>>>
>>>> @Path("{id}")
>>>> public Resource locator() {
>>>> }
>>>>
>>>> @GET
>>>> public void getSub();
>>>> }
>>>>
>>>> we have the same 2 candidates, but get() wins because locator() loses
>>>> due to the text preferring Tmethod to Tlocator.
>>>>
>>>> Whichever way you go, there's absolutely no need for the
>>>> backtracking. The only case where backtracking might be required id
>>>> when two locators have exactly the same Path, but 2.0 correctly
>>>> recommends to report an error in this case.
>>>>
>>>> FYI, in 1.1, originally sublocators were winning in the latter case,
>>>> and I recall myself when the decision was made to make sure that
>>>> get() in the 2nd example wins, but the bottom line is that both get()
>>>> and locator() has always been two candidates to be selected from.
>>>>
>>>> We have tests on the above and the documentation on this case.
>>>> It is backward-incompatible spec change, please check 1.1 text.
>>>>
>>>> We have to keep 1.1 behavior, we can not break the existing code with
>>>> 2.0
>>>>
>>>> Thanks, Sergey
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -- Santiago
>>>>>
>>>>> On May 17, 2013, at 8:59 AM, Bill Burke <bburke_at_redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/17/2013 4:35 AM, Sergey Beryozkin wrote:
>>>>>>> Hi Bill
>>>>>>> On 17/05/13 04:41, Bill Burke wrote:
>>>>>>>> Let me give you an example:
>>>>>>>>
>>>>>>>> Given this request:
>>>>>>>>
>>>>>>>> OPTIONS /sub
>>>>>>>>
>>>>>>>> This will match:
>>>>>>>>
>>>>>>>> @Path("/")
>>>>>>>> class Resource {
>>>>>>>>
>>>>>>>> @Path("{id}")
>>>>>>>> public Locator locator() { return new Locator();}
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> class Locator {
>>>>>>>>
>>>>>>>> @OPTIONS
>>>>>>>> public String options() { return "OK"; }
>>>>>>>> }
>>>>>>>>
>>>>>>>> But this won't match:
>>>>>>>>
>>>>>>>> @Path("/")
>>>>>>>> class Resource {
>>>>>>>>
>>>>>>>> @GET
>>>>>>>> @Path("sub")
>>>>>>>> public String get() { return "OK"; }
>>>>>>>>
>>>>>>>> @Path("{id}")
>>>>>>>> public Locator locator() { return new Locator();}
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>> Seems to me it will too. @GET method is selected only if no
>>>>>>> @OPTIONS is
>>>>>>> available and in this case it is available.
>>>>>>>
>>>>>>
>>>>>> Check out the spec. It won't match because "sub" is matched in
>>>>>> 2(h). 2(h) says that if there are any non-locator matches, then go
>>>>>> to 3, then 3(a) will abort the request.
>>>>>>
>>>>>> I ran into this very problem when testing against the TCK. The TCK
>>>>>> assumes there is no loopback to Locators and one of the tests
>>>>>> fails. I'm able to fix this problem quite easily, but, I have some
>>>>>> users that reported this as a "bug". They will now "regress".
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>
>>
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com