Hi Stephan,
Marc and I discussed this a while back and we had a proposal to resolve
this (i even implemented it :-) ) but it slipped through the gaps...
The proposal was the following:
1) Rename methods getAncestor* to getMatched*
2) entry 0 in getMatched* is the current matched 'thing'
3) entry 1 (if present) in getMatched* is the parent matched 'thing'
Paul.
Stephan Koops wrote:
> Hi,
>
> is there a way to access the currently matched path in a sub resource
> locator? With UriInfo.getAncestorResourceURIs() you have access to the
> previous matched path, with UriInfo.getAbsolutePath() or getRequestUri()
> you have access to the full path. But I think you have no direct access
> to the currently matched path in a sub resource locator without
> accessing the last ancestor resource URI and append the path segment of
> the current sub resource locator.
>
> So I propose to add UriInfo.getMatchedUri(), which returns the path
> matched until now. In a resource method it qould return the same as
> getAbsoluthPath, perhaps excluding the base reference.
> This method could return the full URI (analogue to getRequestUri() and
> getAbsoluthPath() ) or the relative path (according to
> getAncestorResourceURIs() ). If use the former, we should also add
> UriInfo.getMatchedUriBuilder().
>
> best regards
> Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109