jsr339-experts@jax-rs-spec.java.net

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

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

Here are two JIRAs:

http://java.net/jira/browse/JAX_RS_SPEC-356
(Consider dropping 2-arg constructors) - IMHO safe thing to do

http://java.net/jira/browse/JAX_RS_SPEC-357
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<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
>>