Hi Paul,
I don't know how I was able to produce the behavior I described, but now
it's not possible to reproduce this - all test are running through even
when I invoke getAbsolutePathBuilder on the same UriInfo in different
resources (but I'm sure I really experienced this ;)).
So please excuse the confusion,
cheers,
Martin
On Mon, 2008-02-25 at 12:13 +0100, Paul Sandoz wrote:
> 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
> >>>
> >>>
>