Hi Bill - I've had that test recorded as failing but I thought it was
failing for a different reason.
At the very least IMHO we have not to enforce this current 2.0 dropping
of matching locators at the TCL level, I hope spec leads (this and TCK
specs) will support us.
Thanks, Sergey
On 17/05/13 17:54, Bill Burke wrote:
>
>
> 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.
>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com