[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Re: Re: Re: Re: Why do we need new UriInfo Methods?

From: Sergey Beryozkin <>
Date: Fri, 15 Feb 2013 16:05:01 +0000

Here are two JIRAs:
(Consider dropping 2-arg constructors) - IMHO safe thing to do
Drop Response.getLinkBuilder as it is tricky for a caller to populate
UriInfo on the client side;

Thanks, Sergey

On 15/02/13 15:45, Sergey Beryozkin wrote:
> On 15/02/13 15:25, Santiago Pericas-Geertsen wrote:
>> On Feb 15, 2013, at 4:57 AM, Sergey Beryozkin<>
>> 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