Hi Santiago
On 14/02/13 13:47, Santiago Pericas-Geertsen wrote:
> 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).
>
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 ?
And given static is not quite cool, what are other options apart from
getting a support from UriBuilder ?
Does it make sense at all ?
Thanks, Sergey
> -- 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
> <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
>>>
>