On May 23, 2013, at 9:21 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> 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 ?
It's not a match here, you are comparing two regular expressions using an "=" sign. This is exactly the same thing we did in 1.1. See the definition of the function R.
-- 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
>>
>