users@jersey.java.net

Re: [Jersey] Accessing the response object (in standard JSR311)

From: Jan Algermissen <algermissen1971_at_mac.com>
Date: Tue, 06 Oct 2009 10:50:17 +0200

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.


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
--------------------------------------