Hi Sergey,
>> 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).
>>
BTW, I meant UriBuilder above.
>
> I'm actually not objecting to UriInfo having resolve() & relativize() singe argument flavors, I'm simply pointing to the fact the ones with 2 args have to be made static given that UriInfo state has nothing to do with 'supporting' a 2 arg resolve & relativize ?
They could be static, yes.
>
> And given static is not quite cool, what are other options apart from getting a support from UriBuilder ?
Note that UriInfo is passed as an argument to Link.buildResolved() and Link.buildRelativized(). Thus, this is not a 1-line change.
-- Santiago
>> On Feb 14, 2013, at 8:09 AM, Sergey Beryozkin <sberyozkin_at_talend.com
>> <mailto: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
>>>> <mailto: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
>>>>>> <mailto: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
>>>>>>>> <mailto: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
>>>>>>>>> <mailto: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
>>>>
>>