On Wed 14 Dec 2011 05:25:58 PM CET, Sergey Beryozkin wrote:
> On 14/12/11 13:37, Marek Potociar wrote:
>>
>>
>> On Wed 14 Dec 2011 11:47:47 AM CET, Sergey Beryozkin wrote:
>>> Hi
>>>
>>> I've had a closer look at the updated Request interface and IMHO it's grown into a uber-interface that exposes much of
>>> the imformation which is already available in other interfaces which can be injected into the application code and
>>> also exposes the methods that the application code should not even see.
>>>
>>> 1. HttpHeaders is there to provide the info about the current headers;
>>> Request offers RequestHeaders which mainly duplicates what HttpHeaders can offer; would it make sense to get Request
>>> updated to return HttpHeaders instead and may be just drop RequestHeaders;
>>
>> HttpHeaders are incomplete in terms of type-safe support of request headers. However, they are too request specific to
>> be reusable in the response. Thus the new separate set of interfaces was designed with the intent to make HttpHeaders
>> deprecated (via javadoc wording) over time.
>>
>
> Why did you decide to avoid adding extra methods to HttpHeaders and retaining them for the purpose of representing the
> request headers ? Adding new methods should not break the legacy client code and we'll have one less interface,
> instead of keeping 2 mostly duplicate interfaces around for years ?
Please understand that we want to keep the amount of potential BW incompatibilities to an absolute minimum. In case of
Request/Response the extension greatly outweighed the potential drawbacks of the interface extension. In case of
HttpHeaders though, extending the interface does not bring enough value to be justified, esp. as the extension would
result in an asymmetric API (HttpHeaders on request side and ResponseHeaders on the response side) as well as we are far
less sure that people are not extending this interface (e.g. to provide extra type-safe http getters).
>>>
>>> 2. UriInfo offers all the methods needed to get to the current request/base/absolute uri, Request duplicates 5-8
>>> methods from UriInfo
>>
>> I assume you are referring to something that's being already discussed in a different thread.
>>
> I was simple summarizing here;
>
>>>
>>> 3. JAX-RS is about MessageBodyReaders making it possible for users to write the code like this:
>>>
>>> public void post(Book book);
>>>
>>> Having Request all of those methods that users are supposedly can/should (?) call instead does not make sense to me.
>>> Request takes upon the MBR and in fact the Providers functionality here.
>>
>> No it doesn't. Request encapsulates the logic provided by handlers as well as mbr/mbw providers. In some cases it may
>> make sense to use request in other cases it doesn't. It's just a tool for a job. It's no different from any other
>> component in (any) API.
>>
>>>
>>> For example, now instead of composite MBRs injecting Providers they will/should inject Request instead ?
>>
>> Most certainly not.
>
> Why does that mean ?
Perhaps I do not fully understand, what are you trying to point out, but I really don't see a reasonable connection
between Request and Providers. MBR is a lower level concept than request. So I assume that most certainly people will
still want to stick to Providers in their MBRs.
>
>> But obviously, it is a very broad question so a correct answer would be "It depends."...
>> Yet, I can only repeat that it is not our job to absolutely protect people from doing stupid things with the tools we
>> provide.
>>
>
> I find this argument being bizarre; first we offer 5 options to users to get to the input stream from their
> application code and then we say, or lets tell not be stupid and don't try to use Request IS getters when you get Book
> in the signature.
I never said that. I said that injecting Request in MBR would be most likely not something you would want to do (i.e.
stupid). Obviously, injecting a request into a resource or a resource method is a valid thing to do. Similarly,
injecting entity input stream to a resource method is also a valid thing to do.
I am sorry, but I fail to understand your point here. From what I understand so far, you seem to be mixing message body
readers, injection of Providers as well as application-level resource method signatures into a single question that
seems to evolve around using injected Request in some ambiguous use case.
Perhaps it would help if you could share a specific example of the issue you see?
>
>>>
>>> I know that filters do need such methods - hence I propose to move these input stream/etc getters away from Request
>>> and make them visible on relevant filter/handler interfaces
>>
>> Consuming streams is already allowed by JAX-RS 1.x spec also in the resource methods. It is quite useful in fact if you
>> need to process large entities.
>>
> I'm getting annoyed, I'm sorry.
> Yes, that is exactly what I'm saying, we let people do InputStream or Book in the signature. Please justify why we
> also should let them do the same via Request in the application code
For the very same reasons we let them inject Request into resources or resource methods already now - e.g. to be able to
produce a response or work with conditional tags etc.
Marek
>
> Thanks, Sergey
>
>> Marek
>>
>>>
>>> Sergey
>
>