On 5/17/2013 11:27 AM, Sergey Beryozkin wrote:
> On 17/05/13 16:00, Sergey Beryozkin wrote:
>> On 17/05/13 15:39, Bill Burke wrote:
>>>
>>>
>>> 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.
>>>
>> This is a breaking change in 2.0.
>>
>> In 1.1 this can not happen:
>> https://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-360003.7.2
>>
>> Bill, what test are you talking about ? I will challenge it
>>
>> Santiago, comments please ? I know we now support selecting between
>> candidates between multiple root resources with the same path, but we
>> can't lose sub resource Locators like this. With 1.1 in Bill example,
>>
>> OPTIONS /sub
>>
>> will be absolutely properly matched to Locator.options
>>
>> in 2.0 we have a non-match
>>
> Note subresource locators are not dropped immediately, they will be
> eliminated later on in 2.f in JAX-RS 1.1.
>
> We have to fix 2.0, 2.1 now I guess
>
com.sun.ts.tests.jaxrs.ee.rs.get.optionSubTest() triggered a fail for me
indirectly
There was a locator like this:
@Path("sub")
@GET
public String get() {...]
@Path("{ID}")
public Locator locator(@PathParam("ID") int id) {...}
My old algorithm went to check the locator after failing to find OPTIONS
/sub on get() method and got a 400 because "sub" can't be turned into an int
There may be other tests that fail, but I'm only halfway through the TCK.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com