Hi Paul,
Paul Sandoz schrieb:
> 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'
something like 2 and 3 I've already had in mind, but the current matched
'thing' is no ancestor, so I didn't proposed this ...
But with the name getMatched*() it sounds good.
best regards
Stephan
>
>
> 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
>>
>