On Feb 14, 2013, at 9:20 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
>>
>>>
>>> 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.
>
> I guess this would make it tricky to delegate to the concrete JAX-RS implementation to actually implement these methods ?
There's always that, 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.
>>
>
> I see Link.Builder only needs 1 arg UriInfo resolve & relativize ? I've actually implemented Link.Builder with this assumption...
Right, what I meant is that if we move all the methods to a class other than UriInfo, we'd need to update the methods above. Moving only the 2-arg methods isn't a good idea IMO as it just disconnects things even more.
-- 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
>>>>>>
>>>>
>>
>