Hi Marc
Thanks for your analysis and apologies for confusing the section id, I
did read the spec though :-) but I didn't have it in front of me at the
time of writing the message.
My email reader does not prepend '>' to your text so I'll prepend S.B to
my comments.
> In CXF, the 'at least' once match is actually done, seems like it
> does not break the algorithm, but I'm not sure. So during this match
> '/' is successfully matched against both listBars and readBars due
> with the help from corresponding reg expressions.
>
> Here I'd like to ask : am I correct in assuming that the 'at least
> once' run through 3.7.2 should be attempted in this case ?
>
I'm not exactly sure what you mean by an "at least one" match but the
resource method designator (@GET etc) doesn't appear in the algorithm
until 3.7.2, bullet 3 (after you've identified the object to handle
the request).
S.B > What I mean is that after the initial match in 3.7.2, we can't go
through 3.7.2/bullet2 , because immediately at 3.7.2/2.a the condition
is that if the final matching group produced at 3.7.2 (as part of
selecting the resource class) is 'null' or '/' then we need to go to
3.7.2/bullet3 and in 3.7.2/bullet3 there's no explicit indication (I
don't see it anyway) as to what to do if 'null' or '/' was produced
earlier with respect to selecting the methods like listBar() and
readBar() in my example.
In CXF if the final matching group in 3.7.2 is null, then we assume it's
actually '/' and then we go and attempt to match it against the class
methods despite what 3.7.2/bullet 2.a says. If a resource method has no
@Path annotations like listBar() in my example, then we assume
@Path("/") is there. This gives us the option to run through
3.7.2/bullet2 'at least once'.
Also you say above that "resource method designator (@GET etc) doesn't
appear in the algorithm until 3.7.2, bullet 3 (after you've identified
the object to handle the request)".
This is actually a bit confusing for me too. The object has been
identified in 3.7.2/bullet2, and the (final) method has been selected
there as well, in 3.7.2/2g, 2.h:
(g) Set Rmatch to be the first member of E
(h) If Rmatch was derived from Tmethod then go to step 3.
It seems to me that 3.7.2/bullet 2 already produces the final method,
but still in 3.7.2/bullet3 there's a need to sort multiple methods based
on ProduceMime/ConsumeMime and do a designator match...
I'm wondering, what would happen to algorithm if 3.7.3/bullet 3 was
removed and instead 3.7.2/bullet2,f were expanded like this :
(f) Sort E using ProduceMime/ConsumeMime, 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
Tmethod ahead of those derived from Tlocator.
And also update 3.7.2/bullet2,d
(d) Filter E by matching each member against U as follows:
* Remove members that do not match U or do not match request designator
(if derived from Tmethod).
I'm not sure but it seems that a 'the number of literal characters in
each member' is that sort of criteria which users may not want to depend
upon as far as selecting between multiple methods is concerned - unless
I'm missing some practical scenarios here - so the sorting might be
simplified. Not sure about a number of capturing groups though...
I'm sorry if I've lost myself while trying to think too hard here :-)
> If yes, then it seems to me that the only criterias for choosing
> between listBars and readBar are those specified in 3.7.2.f and they
> all actually seem equal to me (source is the same - both are
> resource methods, numebr of capturing groups is the same - none,
> except perhaps for a number of literals after substitution is also
> the same - 1 for readBar, 0 for - listBar)
>
> Is it correct or not ?
>
> If not then all the selection needs to be done in 3.7.f.3 and I can
> not see there how listBar should be selected instead of readBar.
>
Yes, that's true. There does seem to be an edge case for @Path("/"),
probably a result of our special-casing of '/' as the path segment
separator. I'm not really sure what to do about it though. One thing
we could do is to change the regexp expansion for a path parameter
from (.*?) to (.+?), if we did that then @Path("{foo}") would no
longer match an empty path segment. so the two @Path you have in your
example wouldn't both match /1/.
Another approach would be programmatic:
@Path("/{a}")
public class FooClass {
@GET
public Bars listBars() {...}
@GET
@PATH("/{e}")
public Bar readBar(@PathParam("e") String e) {
if (e==null || e.length()==0)
throw new WebApplicationException(Response.seeOther(a).build());
...
}
}
S.B. > (.+?) is something Brad (who raised the issue on CXF list was
also proposing). If replacing (.*?) to (.+?) won't have any negative
effect on the rest of the algorithm then it seems like the best
approach.
Perhaps another option is to require that rather than sort matching
members
based upon number of capturing groups or literal characters left after
substitution, just sort matching members based on the total number of
characters in @Path in ascending order in which case listBars would win,
so something like this would probably fix the issue :
(f) Sort E using ProduceMime/ConsumeMime, the total number of characters
in @Path in ascending order, and the source of each member as tertiary
key sorting those derived from Tmethod ahead of those derived from
Tlocator.
Once again, I'm not sure I'm well understanding what I'm saying here at
this time of the day so my apologies if it does not make sense :-)
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