On 23/05/13 14:14, Santiago Pericas-Geertsen wrote:
>
> On May 23, 2013, at 7:32 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
>> So, typing for my own understanding of the updated text.
>>
>> Issue 405:
>>
>> @Path("/")
>> public class Resource {
>> @POST
>> @Path("{id}")
>> public void post();
>>
>> @Path("sub")
>> public Resource locator() {
>> }
>>
>> @GET
>> public void get();
>> }
>> }
>>
>> (FYI, I just fixed a type there, I suspect I introduced it while working on issue 406), sorry :-), we have, in the following order
>>
>> 1. locator()
>> 2. post()
>>
>> 3.7.2.h: we exclude locator() and check if M is empty.
>> M is non empty, so we move to 3; locator() is lost
>
> No, M is empty now because R_match is constructed from @Path("sub"), and there is no sub-resource method (just a locator) that has that path, which is the condition in the construction of set M.
Are you sure ?
g) Set Rmatch to be the first member of E
Yes - it is a locator() match.
(h) Set M to be the set of sub-resource methods (excluding sub-resource
locators) as follows:
M = {sub-resource methods D of all classes in C where Rmatch = R(TD )}
Where RMatch = R(Td) which represents the resource method matches and
resource method matches do not have to be exact matches, right ?
Resource method has @Path("{id}") - this matches ("sub")
So, still does not work
Sergey
>
> -- Santiago
>
>>
>> Definitely does not work as expected
>>
>> Thanks, Sergey
>>
>> On 23/05/13 11:11, Sergey Beryozkin wrote:
>>>
>>> On 23/05/13 11:02, Sergey Beryozkin wrote:
>>>> Hi Santiago
>>>> On 22/05/13 15:27, Santiago Pericas-Geertsen wrote:
>>>>> Hello Experts,
>>>>>
>>>>> See attachment. Steps (2h) and (2i) have been fixed based on the
>>>>> recent discussions. Step (2h) had a rather obvious condition missing.
>>>>> Step (2i) was missing the (less obvious) part about invoking the
>>>>> locator.
>>>>>
>>>>
>>>> This is what the updated 2.h says:
>>>>
>>>> Set M to be the set of sub-resource methods (excluding sub-resource
>>>> locators) as follows:
>>>> M = {sub-resource methods D of all classes in C where Rmatch = R(TD )}
>>>> and go to step 3 if M = {}.
>>>>
>>>> I don't see how it fixes a BC issue identified in
>>>>
>>>> https://java.net/jira/browse/JAX_RS_SPEC-405
>>>>
>>>> The way 2.h is written now still loses the locator even though, in
>>>> JAX_RS_SPEC-405 example, it comes in front of the resource method.
>>>
>>> The text says go to step 3 if M = {}. But in JAX_RS_SPEC-405 example M
>>> is not empty. Can you copy the text from JAX-RS 1.1:
>>>
>>> - Set Rmatch to be the first member of E
>>> If Rmatch was derived from Tmethod, then set
>>> M = {subresource methods of O w here R(T ) = R } method match
>>> and go to step 3.
>>>
>>> Now, this will work. We need to select the 1st member first and then
>>> make the decision, either continue with the locator (if it happens to be
>>> on top) or else, drop all the locators, and work with the resource
>>> methods only
>>>
>>> Have you tried applying your text to the example at JAX_RS_SPEC-405 ? If
>>> it works for you the can give me a favor and type it here ?
>>>
>>> Thanks, Sergey
>>>>
>>>> Sorry, I may be slow a bit.
>>>> Thanks, Sergey
>>>>
>>>>> -- Santiago
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
>