I missed something :
> Aren't we talking about selecting methods in the bullet 2 ?
Wanted to say
> Aren't we talking about selecting methods in the bullet 2 *as well* ?
Cheers, Sergey
----- Original Message -----
From: Sergey Beryozkin
To: users_at_jsr311.dev.java.net
Sent: Wednesday, May 14, 2008 6:06 PM
Subject: Re: Selecting between method candidates
Hi,
>> So taking the example I provided, would the 'descending order' bit
>> still result in a readBar being selected() for requests like /1/ ?
>>
> No, because that only applies to selecting the object that will handle
> the request. Choosing amongst the methods of the chosen object is then
> done in bullet three. Essentially the algorithm has three parts:
>
> 1. Find the root resource class
> 2. Traverse sub-resource locators
> 3. Find the method
>
> Sorting by literal template characters and capturing groups on happens
> in 1 and 2.
What does the following mean in bullet 2 ?
(g) Set Rmatch to be the first member of E
(h) If Rmatch was derived from Tmethod then go to step 3
May be you consider a resource class be a subresource locator too, during the first iteration, but either way, when a resource class has been found, clearly the object represents that very resource class during the first iteration, and during that iteration a match against all Tmethods is attempted. Aren't we talking about selecting methods in the bullet 2 ?
As I said earlier, it's not clear to me at all why, after we have a match derived from a concrete Tmethod in bullet 2.h, we're still talking about sorting method candidates in bullet 3 (though using different criterias), may be it's just me ...
>
>> @Path("/{a}")
>> public class FooClass {
>>
>> @GET
>> @PATH("/")
>> public Bars listBars() {...}
>>
>> @GET
>> @PATH("/{e}")
>> public Bar readBar(@PathParam("e") String e) {
>> }
>> }
>>
>> readBar() has 1 capturing group so wins here as it goes first. The
>> number of literal characters is the same in both cases (just '/').
>> Should we have 'the number of capturing groups as a secondary key
>> (*ascending* order)' instead ?
>> What do you reckon about the feasibility of (.+)? being introduced ?
>> This will lead to no uncertainties at all in this case ?
>>
> I'm beginning to think that this would be the best solution but I'd
> like to think about it some more. There are some downsides to consider
> too, e.g.: @Path("foo{ext}") would no longer match "foo" so you'd need
> extra methods or classes to handle optional path parameters.
Ok, thanks for looking into it.
Cheers, Sergey
>
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland