On 5/17/2013 10:35 AM, Sergey Beryozkin wrote:
> On 17/05/13 15:32, Bill Burke wrote:
>>
>>
>> On 5/17/2013 9:40 AM, Sergey Beryozkin wrote:
>>> Hi Bill,
>>> On 17/05/13 14:35, Sergey Beryozkin wrote:
>>>> On 17/05/13 13:59, Bill Burke 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();}
>>>>>>>
>>>>>>> }
> Well, both Resource methods are candidates, and those candidates which
> are subresource locators lose to those which are not
>
The are not both candidates. Look at Step 2(h). It says goto STep 3 if
set M is not empty. It explicitly says set M excludes sub resource
locators.
So, in the example set M is not empty and it moves to Step 3, which then
results in an exception. Again, the TCK expects this behavior.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com