Sergey,
Please see resolution in corresponding JIRA [1]. If you re-open, please provide solutions to the issues outline there (complexity of UriInfo and variables in operations like relativize).
-- Santiago
[1]
http://java.net/jira/browse/JAX_RS_SPEC-342
On Feb 14, 2013, at 8:09 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> I'd like to return to this thread, specifically, given that
>
> UriInfo can be used to retrieve the current request and base URI,
> why do we have
>
> UriInfo.resolve(URI uri1, URI uri2)
> UriInfo.relativize(URI uri1, URI uri2)
>
>
> I think Bill's idea on having UriBuilder having similar methods makes sense,
>
> We can have
>
> UriInfo.resolve(URI uri)
> UriInfo.relativize(URI uri)
>
> and
>
> UriBuilder.resolve(URI uri)
> UriBuilder.relativize(URI uri)
>
> so when the user has 2 URI to deal with, the following will work:
> UriBuilder.fromUri(uri1).resolve(uri2);
> UriBuilder.fromUri(uri1).relativize(uri2);
>
>
> IMHO, if UriInfo's representation of the current request does not contribute to implementing
>
> UriInfo.resolve(URI uri1, URI uri2)
> UriInfo.relativize(URI uri1, URI uri2)
>
> then these 2 methods should be removed from UriInfo
>
> Thanks, Sergey
>
>
> On 31/01/13 14:44, Santiago Pericas-Geertsen wrote:
>>
>> The proposal is an improvement to the Link class, and the idea is that client applications will operate with Link instances returned from responses. We've added some machinery so that these links could be easily "followed".
>>
>> OTOH, I see that the Javadoc for methods in Response that return Link have not been updated to clarify how these links are resolved. We discussed the idea of automatically resolving these links with respect to the request URI. This needs to be fixed.
>>
>> The need to relativize (rather than resolve) links on the client seems far less common, to be honest.
>>
>> -- Santiago
>>
>> On Jan 30, 2013, at 9:09 AM, Bill Burke<bburke_at_redhat.com> wrote:
>>
>>> Its not much of an extra step, and then you are not constrained to use the methods only on the server. A client may also want to construct resolved and relative URIs.
>>>
>>> UriBuilder.fromUri(uriInfo.getBaseURI()).relativize(uri);
>>>
>>> You may also be relativizing/resolving often from a uri template:
>>>
>>> UriBuilder.fromResource(resourceClass).path(resourceClass, "getCustomers").resolve(uri, "12345");
>>>
>>>
>>>
>>> On 1/30/2013 8:39 AM, Marek Potociar wrote:
>>>> IIRC, it's was a matter of the extra step required. UriInfo has enough information to be able to relativize any URI wrt. request URI. Which is what you essentially always want to do when sending back relative links.
>>>>
>>>> Marek
>>>>
>>>> On Jan 30, 2013, at 1:40 PM, Bill Burke<bburke_at_redhat.com> wrote:
>>>>
>>>>> Why aren't the relativize and resolve methods in UriBuilder?
>>>>>
>>>>> On 1/30/2013 5:41 AM, Marek Potociar wrote:
>>>>>> Taking back my comment - I'm sorry, I misread the original request. I thought we're talking about resolveTemplate() methods.
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>> On Jan 30, 2013, at 11:23 AM, Marek Potociar<marek.potociar_at_oracle.com> wrote:
>>>>>>
>>>>>>> We need those to align with WebTarget and to support some of its methods. We also discussed this IIRC.
>>>>>>>
>>>>>>> I'm strongly against removing the methods.
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>> On Jan 28, 2013, at 11:49 PM, Bill Burke<bburke_at_redhat.com> wrote:
>>>>>>>
>>>>>>>> relatives and resolve. I don't seem to recall us discussing this.
>>>>>>>>
>>>>>>>> -1 for these new methods. We don't need to pollute the API with esoteric use cases.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Bill Burke
>>>>>>>> JBoss, a division of Red Hat
>>>>>>>> http://bill.burkecentral.com
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>