Hi,
Santiago explained me why the current text works.
As I managed to grasp earlier, Rmatch in Step 2.h was indeed pointing to
a locator @Path("sub") value.
What I could not see was that in step 2.i, it was indeed that Rmatch
obtained in previous step was to be compared literally with the regular
expressions from set containing resource matches. In there we have
"{id}", "sub" not equals to "{id}", we have an empty set, therefore, we
continue with the locator.
I need my holidays now (starting next week :-)) !
Thanks all,
Sergey
On 23/05/13 14:47, Sergey Beryozkin wrote:
> Santiago, I'm sorry, but I start losing my patience. And I can accept
> I'm just not there as far as my knowledge of the mathematical language
> is concerned.
>
> Where is that Rmatch definition you are referring to ? I do not see it.
>
> I'd like to kindly request you to run the example though the updated
> text exactly as I did it for you when you asked me to when I said the
> 2.0 algorithm was not backward compatible and present this run here
>
> Thanks, Sergey
>
> On 23/05/13 14:39, Santiago Pericas-Geertsen wrote:
>>
>> 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
>>>>
>>>
>>
>
>