On 26/10/11 15:33, Marek Potociar wrote:
>
>
> 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?
>
Sounds OK
>>
>> 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).
>
OK
thanks, Sergey
> 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
>>
>>