On May 14, 2008, at 1:08 PM, Sergey Beryozkin wrote:
> 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* ?
>
Bullet 2 is checking to see whether the current object consumes the
remainder of the request URI (2.a), whether it contains sub-resource
methods that consume the remainder of the request URI (2.h), or
whether it contains a sun-resource locator that matches the start of
the remainder of the request URI (2.i). Its not actually selecting a
method, its checking to see if the object has a method that matches
the URI template -- it doesn't compare the supported method (GET, POST
etc) or consume or produce mime at this point.
Marc.
>
> 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
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.