On 10/16/2011 05:58 PM, Sergey Beryozkin wrote:
> Looks great, especially having a single Response entity.
>
> I'd propose to drop Response.bufferEntity() as it has no real use on the server side, and on the client side, when one
> really needs to delay processing a response, one simply can do Response.getEntity(...) and keep whatever the result is
> until later.
Get entity is not guaranteed to buffer the entity (e.g. if it returns a stream). But I will put a "probation" on the
bufferEntity and if we see that it's really not used in our impls later we would drop it. How about that?
>
> The other thing is whether we can change Response.getMetadata() returning MultivaluedMap<String, String> ? I think that
> in JAX-RS 1.1 Response is mainly processed by the server runtime and is not visible to writers. In CXF Response is
> visible on the client side but that API is not a standard one and besides I think dealing with MultivaluedMap<String,
> String> is simpler anyway.
Get metadata will be deprecated (in terms of javadoc-ing that the new getHeaderMap() method should be used instead).
Marek
>
> Cheers, Sergey
>
>
>
> On 21/09/11 12:34, Marek Potociar wrote:
>> Hello experts,
>>
>> please review the proposed change for merging HttpRequest and HttpResponse into the existing JAX-RS 1.x Request/Response
>> API:
>> http://java.net/projects/jax-rs-spec/sources/git/revision/8fd5db313234854b3b3e711d66f2073996e7d34a
>> (Please ignore the listed spec text files and focus on the API)
>>
>> In particular the change consists of removing the HttpRequest and HttpResponse interfaces and *adding new methods* to the
>> - Request interface
>> - Response abstract class
>> - Response.ResponseBuilder abstract class
>>
>> The proposal aims for reducing the confusion, simplifying things and cleaning up the overlapping concepts in the API.
>>
>> While the proposed changes introduce a risk of BW incompatibility, the problem is mainly affecting JAX-RS implementation
>> providers, which does not seem to be an issue itself. However, although we don't expect any users to extend and
>> implement the existing req/resp API classes, we cannot be sure if we did not miss any important or widely used use case,
>> so we would like to ask for your cooperation in reporting any such use cases presently used in a production by either
>> you or your clients/community. Please, be as specific as possible with each such use case.
>>
>> FWIW, we have already checked our intent within the JavaEE architects and spec leads group and while personal opinions
>> of individual spec leads are divided, we are free to proceed with the change at our own discretion. Also, we would
>> certainly not set a precedent - some other APIs already made similar changes in the past.
>>
>> I am looking forward to your feedback.
>>
>> Thank you,
>> Marek
>
>