On 20/12/11 16:02, Marek Potociar wrote:
> Might make sense. Please, elaborate on the concrete proposal including
> the potential use cases you see.
I believe the methods you had removed from Request were among other
things, meant to help the client filters to check what the current URI
is and such;
I proposed to get those methods 'collapsed' into a reference to UriInfo
but UriInfo has some methods which only make sense on the server-side.
So this proposal is not a new one, but rather is an attempt to see if it
makes sense to get Request providing a reference to request URI but also
to minimize the duplication by getting UriInfo split
I'm not sure now if it's a good idea, once more interface; but I believe
you also added an injectable Uri interface - so may be that can become a
super interface for UriInfo, not really sure
Sergey
> All other EG members, please
> participate any client-side use cases that would support this change.
>
> Thanks,
> Marek
>
> On Tue 20 Dec 2011 03:44:56 PM CET, Sergey Beryozkin wrote:
>>>> http://java.net/jira/browse/JAX_RS_SPEC-154
>>>
>>> Agreed
>>
>> I'm having another thought about it, though do agree with the resolution.
>> The purpose of this email is to explore the options around refactoring UriInfo. Most of UriInfo's methods can be
>> generally useful on both sides, so the original methods Marek added to Request could've been useful on the client side.
>>
>> What do you think about extracting some commonly useful methods to UriInfo superintertface, such as RequestURI for
>> example ?
>> UriInfo extends RequestURI ?