On Oct 6, 2009, at 2:00 PM, Paul Sandoz wrote:
>
> On Oct 6, 2009, at 10:50 AM, Jan Algermissen wrote:
>
>>
>> On Oct 6, 2009, at 10:39 AM, Paul Sandoz wrote:
>>
>>> On Oct 6, 2009, at 10:29 AM, Jan Algermissen wrote:
>>>>>
>>>>> It is currently not possible. If one needs to do that then a
>>>>> message body writer can be used. For example you could write
>>>>> your own version of StreamingOutput and your own message body
>>>>> writer that supports the setting of headers e.g.
>>>>>
>>>>> public MyStreamingOutput {
>>>>> write(MultivaluedMap headers, OutputStream out);
>>>>> }
>>>>>
>>>>
>>>> Hmm, I think I don't get it - how would the MessageBodyWriter or
>>>> the e.g. getResource method ever get hold of the response object?
>>>>
>>>
>>> It would not get hold of the Response object. The message body
>>> writer is passed the response headers, which can be modified. So
>>> you could have a message body writer as follows:
>>>
>>> @Provider
>>> @Produces({"application/octet-stream", "*/*"})
>>> public final class StreamingOutputProvider implements
>>> MessageBodyWriter<MyStreamingOutput> {
>>>
>>> public boolean isWriteable(Class<?> t, Type gt, Annotation[] as,
>>> MediaType mediaType) {
>>> return MyStreamingOutput.class.isAssignableFrom(t);
>>> }
>>>
>>> public long getSize(StreamingOutput o, Class<?> type, Type
>>> genericType, Annotation[] annotations, MediaType mediaType) {
>>> return -1;
>>> }
>>>
>>> public void writeTo(StreamingOutput o, Class<?> t, Type gt,
>>> Annotation[] as,
>>> MediaType mediaType, MultivaluedMap<String, Object>
>>> httpHeaders,
>>> OutputStream entity) throws IOException {
>>> o.write(mediaType, httpHeaders, entity);
>>> }
>>> }
>>
>>
>> Hmm, that's what I thought I should do but somehow (it seemed) it
>> did not work - so I was confused. Sorry.
>>
>> I guess I tried to move the header-setting logic into the Resource
>> class[1] because I feel uncomfortable about moving Response
>> handling logic into the Writer class (which I understand to be more
>> like a mapper than a handler). But it seems this distribution of
>> responsibilities is (currently) inevitable.
>>
>
> 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. Setting the response code and
location header inside the writer seems bad design.
But maybe a wrapper oround the domain object that is populated with
the request circumtances is the best solution right now.
>
> 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???
Jan
> Paul.
>
>
>
>> Jan
>>
>> [1] using injected httpHeaders which obviously would not work
>> because they are request headers
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>> Paul.
>>
>> --------------------------------------
>> Jan Algermissen
>>
>> Mail: algermissen_at_acm.org
>> Blog: http://algermissen.blogspot.com/
>> Home: http://www.jalgermissen.com
>> --------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--------------------------------------
Jan Algermissen
Mail: algermissen_at_acm.org
Blog:
http://algermissen.blogspot.com/
Home:
http://www.jalgermissen.com
--------------------------------------