Hi,
see opinions above the items:
> 1) Since we allow @Path("id") PathSegment i propose we have an
> equivalent method on UriInfo.
IMO the current is enough, but I'm open.
> 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.
+1
> 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.
Let path parameters ans path segments at UriInfo, so -1 for this detail.
for the other: IMO
* Access to the ancestor resource URIs belongs (also) into UriInfo.
* Put the access to the ancester resources in an interface which
also gives access to the ancestor resource URIs
If UriInfo should be splitted, than my proposal is: create a new
Interface Ancestors with the methods getResourceURIs(),
getResourceURIs(boolean) and getResourcs() with the same semantic as now
in UriInfo (including the proposal 2 above) and remove
UriInfo.getAncestorResources(), but let both getAncestorResourceURIs(.)
with their current semantics (inclduing proposal 2) in UriInfo.
best regards
Stephan