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.
Would also appreciate if you could explain what is the idea behind using
HttpResponse.bufferEntity and HttpResponse.annotateEntity on the server side.
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