On Oct 6, 2009, at 2:50 PM, Jan Algermissen wrote:
>>
>> Sometimes those headers can be added in the application logic but
>> sometimes it makes sense to add/modify without the application have
>> to do work (like adding a boundary parameter to the content-type).
>> So i think the distribution of responsibilities may depend on the
>> use case. A message body writer is responsible for writing a
>> representation and a representation is headers+entity.
>
> Well, yes. But the same writer will be used in different response
> scenarios (e.g. response to 200 GET on Foo-entity vs. 201 response
> to POST to collection of Foo-entities.
Yes, if the Java types that the writer supports is utilized in all
those cases.
> Setting the response code
Note that It is not possible to set the response code in the writer
using standard JAX-RS APIs.
> and location header inside the writer seems bad design.
>
Maybe it depends on whether the instance of Java type to be written
encapsulates appropriate information (modulo the issue setting the
response code).
e.g.
@POST
Created<MyType> post(...) {
MyType t = ...
URI location = ...
return new Created(t, location);
}
But, IMHO, i prefer to to use the Response builder for such cases.
> But maybe a wrapper oround the domain object that is populated with
> the request circumtances is the best solution right now.
>
Could be for your needs.
>>
>> IMHO if you are adding support for streaming multipart/mixed then a
>> message body writer operating on an appropriate type for streaming
>> multipart is probably the best approach.
>>
>> I forgot to point you to this issue:
>>
>> https://jersey.dev.java.net/issues/show_bug.cgi?id=345
>>
>> Another developer has been experimenting with efficient streaming
>> support and has kindly attached some prototype code.
>>
>
> Thanks. But the output stream that is passed to the writers I hope
> does not suffer from inefficiencies such as buffering it on disk???
>
No. In terms of the Servlet implementation it is the OutputStream
obtained from the HttpServlerResponse.
Paul.