Hi
> Just to clarify, the number of template variables is already included
> when sorting (number of capturing groups is directly related to number
> of template variables):
Ok, thanks for the clarification. I was assuming it was a number of groups which a given regex match has returned.
>
> 3.7.2. bullet 1 e: "Sort E using the number of literal characters in
> each member as the primary key (descending order) and the number of
> capturing groups as a secondary key (descending order)."
>
> 3.7.2. bullet 2.f: "Sort E using the number of literal characters in
> each member as the primary key (descending order), the number of
> capturing groups as a secondary key (descending order), and the source
> of each member as tertiary key sorting those derived from T
> method ahead of those derived from T locator."
So taking the example I provided, would the 'descending order' bit still result in a readBar being selected() for requests like /1/ ?
@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 ?
Thanks, Sergey
>
> Marc.
>
>>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland