+1 Paul.
Paul Sandoz wrote:
> 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
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com