Never mind, ignore it please....
IMHO you are misreading it somehow,
Thanks, Sergey
On 17/05/13 15:35, 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();}
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>> 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.
>>>> But get() does not match OPTIONS, it will only match
>>>>
>>>> GET /sub
>>>>
>>>> and it will only match OPTIONS if no OPTIONS handler is available, but
>>>> OPTIONS handler is available.
>>>>
>>>> Now we go to Locator and then we match OPTIONS. The only issue is that
>>>> what happens if Locator has no OPTIONS too, I guess we have missed then
>>>> the opportunity to match Resource.get because GET can be used to match
>>>> OPTIONS if no OPTIONS exist. To be honest I do not see it as a big
>>>> issue,
>>>>
>>>> I believe the spec says that if no OPTIONS handler is available then
>>>> check GET, we have no GET on Locator so we should report all the verbs
>>>> supported by it and its root Resource which is "GET", and it is cheaper
>>>> than calling @GET method as a last resort as doing it may be expensive
>>>>
>>> Got confused here, this is a case of HEAD where GET may be called, did
>>> you mean HEAD ? and if it is OPTIONS then Resource.get can not be
>>> matched at all
>>> \
>>
>> Again, go walk through the algorithm in the spec. The spec algorithm
>> does not check which methods are available until step 3(a).
>>
> Well, both Resource methods are candidates, and those candidates which
> are subresource locators lose to those which are not
>
> Sergey