Hi,
Some proposed changes to UriInfo:
1) Since we allow @Path("id") PathSegment i propose we have an
equivalent method on UriInfo.
2) There is a problem with the ancestor related methods in that they
return n - 1 paths and resource instances, where n is the number of
currently matched path segments. When in a sub-locator method it
makes it hard to get the n'th matched path. When in a constructor it
makes it hard also, since one cannot necessarily determine if the
whole path has been consumed. When in a HTTP method one can get the
final path from a different method in UriInfo, but it seems
appropriate to at least handle all information consistently.
I propose that we rename "Ancestor" to "Matched" and return n matched
stuff consistent for sub-locators, constructors and HTTP methods. The
parent path or resource would aways be at index 1 in the list.
3) UriInfo serves two purposes. Get access to direct information in the
URI, like query, matrix and path segments and get access to
contextual information related to the matching process, like methods
associated with path parameters and the ancestors. It might make
sense to split the interface, for example UriInfo and
UriMatchingInfo, which makes it easier to split the
implementations and for the two to evolve separately.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109