On 08/12/2011 09:26 PM, Sergey Beryozkin wrote:
> Marek, OK, I can get that.
>
> I can't quite pinpoint the potential problem, but I don't like the fact I can't use instances of HttpResponses in server methods where
> Response is supposed to be returned. I guess my point is that the spec takes care of making sure existing Responses are not touched
> but HttpResponses can not be used in the server application code. Not sure it it were a clean solutionre but it seems adding noops (or even impls)
> to existing abstract Response code would not break BW.
Let me try to provide a concise history behind the current state:
- Request is interface and Response is an abstract class.
- We had to provide an extended version for both for the Client API since the existing classes did not fit the needs
- Technically, we could extend the response, but we could not easily extend the request interface without breaking BW.
compatibility
- Also, we had a requirement that Req and Resp should be interfaces, which Response abstract class could not satisfy
- Thus, when introducing a client API, we came with ClientRequest and ClientResponse interfaces
- Later we added interceptors in the picture and saw that the CReq and CResp would be useful on server side too
- I applied some refactoring and converted the client-side classes into general-purpose ones (the origin of the javadoc
bug lies most likely there)
I would need to give it a careful look to see if Response can implement HttpResponse and whether all the existing
Response production points can be converted to HttpResponse. Btw. what are the places you had in mind? Can you enumerate
at least the ones you see now?
>
> Would also appreciate if you could explain what is the idea behind using
> HttpResponse.bufferEntity and HttpResponse.annotateEntity on the server side.
Buffer entity is not particularly useful on the server side (at least I don't see a good use case right now). Annotate
entity is something that was added in anticipation of low-level bean validation support. I guess the method should be
removed for now.
Marek
> I can imagine why I may want to use say HttpResponse.bufferEntity on the client side, perhaps
> for late batch-processing of responses, etc. What is use case on the server side ? Same for HttpResponse.annotateEntity.
>
>
> thanks, Sergey
> ________________________________________
> From: Marek Potociar [marek.potociar_at_oracle.com]
> Sent: 12 August 2011 12:58
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc: Sergey Beryozkin
> Subject: Re: [jax-rs-spec users] [jsr339-experts] HttpResponse and Response
>
> As I just wrote, the idea is really to extend Response API. The reason for another class was that adding methods to a Response interface would break BW compatibility.
>
> Marek
>
> On 12. 8. 2011, at 11:16, Sergey Beryozkin wrote:
>
>> Hi
>>
>> I can see that HttpResponse offers many more useful methods than Response does.
>>
>> I'm wondering if the idea of having HttpResponse extending Response makes sense. I personally see it as a viable option.
>>
>> Basically, HttpResponse in 98% is the specialization of Response.
>> Response gives absolutely everything that a client needs to know about the server response.
>>
>> So if we had most of existing HttpResponse methods pushed down to Response except for setters and annotateEntity meant for client-side filters
>> then the existing client side code operating with Response (well - we do reuse Response in our version of client api) would stay operational.
>>
>> Well - I'm thinking as I'm typing - we could easily use HttpResponse setters in server side filters too - we've had many cases where users wanted to
>> modify Response headers in custom server filters before Response has been written to OutputStream...
>>
>> Which makes me ask: do we really need to have HttpResponse and Response ?
>>
>> thanks, Sergey
>