Hi Martin,
The instance of UriInfo that is injected is a Java proxy to thread local
instance (same applies to all other request-based injectable types).
This ensures that per-request values accessed via injected instances are
correct for concurrent requests on different threads and on subsequent
requests (see com.sun.ws.rest.impl.application.WebApplicationImpl, lines
#133, #327, #525).
> As a solution/workaround one could retrieve a new instance of UriInfo
> when the parent resource creates a new sub-resource, and pass this new
> UriInfo to the sub-resource.
Note that an instance of the same class can be returned from more than
one sub-locator at different positions in the URI hierarchy.
> Or, as you wrote in your posting "Returning
> a class from a sub-locator", the parent resource could use the
> ComponentProvider to inject dependencies into the child resource.
> -> Is this already implemented so that I could upgrade to the latest
> version (trunk)?
No, not yet, i need to think about it a bit more, on second thoughts
ComponentProvider is a bit too low-level. It needs to be at a slightly
higher-level so the developer does not have to specify the life-cycle
when obtaining instances.
Paul.
Martin Grotzke wrote:
> Hi Paul,
>
> what I wanted to point out is that
> AbstractContainerRequest.getAbsolutePath is implemented as follows:
>
> public URI getAbsolutePath() {
> if (absoluteUri != null) return absoluteUri;
>
> return absoluteUri = getRequestUriBuilder().encode(false).
> replaceQueryParams("").fragment("").
> build();
> }
>
> This is used in AbstractContainerRequest.getAbsolutePathBuilder
>
> public UriBuilder getAbsolutePathBuilder() {
> return UriBuilder.fromUri(getAbsolutePath());
> }
>
> (Which is the implementation of UriInfo.getAbsolutePathBuilder)
>
> So, if the application uses the same instance of UriInfo in two
> resources with a different absolute path (e.g. parent and child
> resource), and the parent resource invokes getAbsolutePathBuilder first,
> exactly the same value is returned, if the child resource invokes
> getAbsolutePathBuilder afterwards.
>
> I wonder if this behavior is correct in terms of the specification of
> UriInfo.getAbsolutePathBuilder
> (https://jsr311.dev.java.net/nonav/releases/0.6/javax/ws/rs/core/UriInfo.html#getAbsolutePathBuilder()):
>
> =====
> getAbsolutePathBuilder
> UriBuilder getAbsolutePathBuilder()
> Get the absolute path of the request in the form of a
> UriBuilder. This includes everything preceding the path (host,
> port etc) but excludes query parameters and fragment.
>
> Returns:
> a UriBuilder initialized with the absolute path of the request
> =====
>
> What do you think?
>
> As a solution/workaround one could retrieve a new instance of UriInfo
> when the parent resource creates a new sub-resource, and pass this new
> UriInfo to the sub-resource. Or, as you wrote in your posting "Returning
> a class from a sub-locator", the parent resource could use the
> ComponentProvider to inject dependencies into the child resource.
> -> Is this already implemented so that I could upgrade to the latest
> version (trunk)?
>
> But then the application developer still has to think about, when
> UriInfo.getAbsolutePathBuilder is invoked first and which value will be
> returned then.
>
> Thanx && cheers,
> Martin
>
>
> On Mon, 2008-02-25 at 11:10 +0100, Paul Sandoz wrote:
>> Hi Martin,
>>
>> The reason for getAbsolutePath is sometimes query parameters are used to
>> scope the representation that is returned and one may not be interested
>> in using those same query parameters for constructing a new URI. The URI
>> returned corresponds to that of the request URI minus any query
>> parameters. Thus can be used for building URIs with direct parent/child
>> relationships that are embedded in the returned representation, e.g.
>> GETing an Atom feed containing URIs referencing Atom entries.
>>
>> It is hard to say what is exactly the correct use for UriInfo, i think
>> it can very much depend on your application. We want to ensure that
>> UriInfo captures many of the common the use-cases around
>> accessing/manipulating URIs e.g. a common pattern like the
>> container/entry of Atom.
>>
>> From what you said below it appears there is something missing from
>> UriInfo: the ability to get a URI for the current 'calling context' i.e.
>> a sub-path of the complete request URI path. For example if a
>> sub-resource locator is invoked perhaps we should allow the getting of
>> the current URI path for that locator. In general i think this could be
>> expanded to a breadcrumbs concept of being able to get the current list
>> of URI paths (which can be used to show the hierarchical traversal history).
>>
>> Hope this helps,
>> Paul.
>>
>> Martin Grotzke wrote:
>>> Hi,
>>>
>>> I have some root resource, that creates child resources by itself, not
>>> by using some IoC-features. The parent resource get's the UriInfo
>>> injected, and passes it down to the child resources (e.g. user/widgets
>>> and user/products).
>>>
>>> When some resource invokes UriInfo.getAbsolutePathBuilder, the
>>> absoluteUri is set in AbstractContainerRequest and used for all
>>> subsequent calls to UriInfo.getAbsolutePathBuilder - which might be
>>> ".../user/widgets/" if it has been called for the widgets resource the
>>> first time, even if the absolutePathBuilder was requested from the
>>> products resource.
>>>
>>> What is the intended way of using UriInfo.getAbsolutePathBuilder or more
>>> generally - the usage of UriInfo?
>>>
>>> Thanx && cheers,
>>> Martin
>>>
>>>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109