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
> >
> >
>