On May 13, 2008, at 4:44 AM, Sergey Beryozkin wrote:
>
> it's a non-starter as @Path("{templatevariable}") will win over
> @Path("{a}/{b}"), so
> perhaps the total number of template variables might be used instead
> as an additional sort criteria.
>
> That said, (.+)? might be the better fix, but I reckon I can use 'a
> number of template variables' as the workaround sorting criteria to
> address the issue raised againt CXF...
>
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):
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."
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
>
> ---------------------------------------------------------------------
> 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
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.