On May 21, 2008, at 7:42 AM, Sergey Beryozkin wrote:
>
> I've fixed the issue in CXF (not on trunk) by relying on a "sort by
> a number of capturing groups, ascending order" in bullet 3 as an
> additional and final criteria.
> In bullet 3 we're dealing wih resource methods only (those which
> have GET/POST/etc). After all the other sorting has been done (media
> types, etc) if we have more than one matching resource method then
> the one which have more capturing groups can be safely put at the
> end of the list (in fact the only possibility is that a difference
> in the groups between diffreent resource methods at this stage is
> max 1) as they only got into this list because of the (.*)?.
>
> That is if we have
> Parh("/")
> class Bar {
> @GET @Path("/") a();
> @GET @Path("/{bar}") b()
> }
>
> then a() is always selected with this additional criteria. Perhaps
> it might be worth considering it as a possible fix.
>
I assume that the request is GET / - right ? If it was GET /something
then a() would be eliminated in 2.(d).second bullet.
So far I have not received any negative feedback on the suggestion to
switch the capturing group for a template var to (.+?), this will fix
the issue anyway.
> I've got another quesion though. "Descending order of a number of
> capturing groups" in bullet 2. My understanding it's mostly there to
> address the selection between multiple subresource locators, right ?
Yes.
> Anyway, here's a concrete question :
>
> Parh("/")
> class Bar {
> @Path("/{bar}") SubResource1 a();
> @Path("/{bar}/{foo}") SubResource2 b();
> }
>
> class SubResource1 {
> @Path("/sub1") @GET a();
> }
>
> class SubResource2 {
> @Path("/sub2") @GET a();
> }
>
> Now, if we rely on a "Descending order of a number of capturing
> groups" then a request like
>
> /1/sub1 is matched against b().
>
> is it expected ? If yes then how to ensure a request is delegated to
> a SubResource1.a() in this case ?
>
Bar::b is always used for a URI like /1/sub1. Note however that in
that case SubResource2::a won't be called since Bar::b would consume
all of the path ({bar}=>1, {foo}=>sub1). SubResource2::a would only be
called for a URI like 1/sub1/sub2.
The algorithm doesn't "peek forward" to see if a subresource locator
will actually return an object that can handle the rest of the path,
it can't actually do that without extensive code analysis since a
subresource locator can return any subclass of the return type which
might have additional methods.
Marc.
>
>
> > On May 15, 2008, at 1:52 PM, Sergey Beryozkin wrote:
> >>
> >> Thanks for spending the time on it and all the feedback...
> >> Are you planning to address that issue with (.+)? too as part of
> >> this update (though it's a bit orthogonal to the algorithm itself
> >> but to do with the @Path's value conversion procedure) ?
> >>
> > No, that will be a separate update. I'll first draft a note to the
> > expert group alias to gather any additional feedback on that one.
> >
> > Marc.
> >> Marc Hadley <marc.hadley at sun.com>
> >> CTO Office, Sun Microsystems.
> >>
> ----------------------------
> 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.