Sergey Beryozkin wrote:
> Hi
>
> 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'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 ?
> 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 ?
>
IMO, b() would be matched always because Locator's are supposed to be
dynamically processed/dispatched per request.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com