On 15/02/13 15:25, Santiago Pericas-Geertsen wrote:
>
> On Feb 15, 2013, at 4:57 AM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>>>>
>>>>>
>>>>>>
>>>>>> 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
>
> I'm not sure if there was any discussion about the 2-arg method. As it stands now, the 1-arg method is defined based on the 2-arg. Could we drop the 2-arg method? Possibly, but it won't change the implementation effort and we may miss some use cases that don't fall into the general case.
>
I'd definitely consider dropping a 2-arg ones. We can introduce them
without any BC concerns if even needed, the pros though is that UriInfo
interface will become marginally simpler and it won't have a method
which in its nature is 'static'.
I'll create a dedicated JIRA for further discussion, I guess, as opposed
to reopening the other one, as UriInfo will def retain 1 arg methods at
least....
Cheers, Sergey
> -- Santiago
>