On Mar 13, 2009, at 9:12 AM, Sergey Beryozkin wrote:
>
> From UriBuilder.buildFromEncoded :
>
> * <p>All instances of the same template parameter
>
> * will be replaced by the same value that corresponds to the
> position of the
>
> * first instance of the template parameter. e.g. the template "{a}/
> {b}/{a}"
>
> * with values {"x", "y", "z"} will result in the the URI "x/y/x",
> <i>not</i>
>
> * "x/y/z".
>
>
> Can someone explain please the rationale behind it ?
>
The rationale is that the template says that {a} is included twice. It
would be odd for two different values to be used.
> It seems inCosistent with the way PathParams handle a similar
> situation, as the PathParam java docs say :
>
> * <p>The injected value corresponds to the latest use (in terms of
> scope) of
>
> * the path parameter. E.g. if a class and a sub-resource method are
> both
>
> * annotated with a {_at_link Path} containing the same URI template
> parameter, use
>
> * of {_at_code PathParam} on a subresource method parameter will bind
> the value
>
> * matching URI template parameter in the method's {_at_link Path}
> annotation.</p>
>
>
> So if we have
>
> @Path("{a}/{b}")
>
> class Resource {
>
> @Path("{a}") void method(@PathParam("a") String a);
>
> }
>
> then x/y/z with result in 'z' being bound to a path parameter,
>
Right, the reason for this was to support recursive sub-resource
locators.
> but if we have uriBuilder.path("{a}/{b}/{a}").build("x", "y", "z")
> then the result will be /x/y/x
>
> I think in the least it's problematic in the context of a client
> application creating a URI to send a given request to
>
Possibly but if it causes problems its straightforward for the
developer of the service to choose different names for each path
component.
Marc.