Yes, my implementation has always supported backtracking. It sucks that
I have to hobble 4+ year old code that some users depend on just because
of the TCK. I think the algorithm could have been simplified by just
stating that more specific mappings take precedence and be done with it
instead of the 2-3 pages of hard to read pseudo-code algorithm-speak.
Just my 2cents.
On 5/17/2013 1:15 PM, 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?
>
> -- 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com