Hi
On 14/02/13 18:49, Santiago Pericas-Geertsen wrote:
>
> 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.
>
I have this feeling I'm not following something simple :-).
- Link.Builder only needs a 1-arg related UriInfo method.
- Same I'd assume is the case for the custom application code working
with the injected UriInfo
Question: what is the use case for getting related 2-arg UriInfo methods
called, as far as dealing with the current request or response is
concerned ?
I guess the answer may be found in the earlier discussion about
expanding the support for Links, but I'd really appreciate some
clarification here
Thanks, Sergey
> -- 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
>>>>>>>
>>>>>
>>>
>>
>