Andy - hope you're reading it. If you could test the following then it will be
appreciated a lot:
@Path("/")
public class Resource {
@Path("{var:.+}")
public Resource subresource() {
return this;
}
@GET
public String getString() {
return "1";
}
}
GET /bar
is apparently will cause JAXRS invoker to use a '|' character after subresource() has beein invoked, but it should be just '/' so
that getString() method is invoked.
Andy and myself looked into this issue and Andy helped me to figure out what
the issue is (thanks Andy :-)).
Basically, the above works quite well in CXF and getString() is invoked on Resource (acting as a subresource after subresource() has
been invoked), with '/' being the path value matched against a default @Path("/") for getString().
Now, as soon as the capturing groups are introduced in the custom regular
expressions, as in :
@Path("{var:(.)+}")
it causes issues during the subsequent subresource resolution.
The problem with user-added capturing groups is that they affect the way the matching works. Internally, custom regular expressions
such as '(.)+' are also captured. URITemplate will assign a matching group value, starting from 1 to template variables and use the
next matching group to capture the value to be used during the subsequent, if any, subresource resolution.
Now, with the extra capturing group introduced by a user, the final capturing group is *erroneously* assumed to be, in this case,
the last matching symbol of the matching expression, ex,
given "/bar" and @Path("{var:(.)+}"), it will be 'r' which will be used to look
for a subresource method.
Now, there's a possible 'fix' which will work only when the whole Path value will contain a single custom regex with extra capturing
groups like ("{var:(.)+}", which is to always use matcher.groupCount() as an index for the the final matching group but it will stil
not work if we have something like
@Path("{var:(.)+}/bar/{foo}")
because this user-added group will affect the value for {foo}.
So, basically, what can be advised is to :
* avoid adding capturing groups to custom regular expressions used by
subresource locators
* if you really really need them (ex, for positive lookbehinds) then use non-capturing groups or avod adding such expressions on
subresource locators (that is @Path("{var:(.)+}") will work ok on the plain resource methods)
hope it helps, Sergey
