Sergey,
Here are the changes based on feedback received:
1) Dropped 2-arg methods from UriInfo
2) Updated resolve and relative methods in Link.Builder replacing UriInfo by URI
3) Samples updated
I believe this addresses all the issues raised by you and Bill.
-- Santiago
PS: The number of open issues is down to 0!
On Feb 15, 2013, at 11:05 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> 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
>>>
>
>