Re: JSR311: Problem with StreamedOutput model

From: Stephan Koops <>
Date: Thu, 13 Mar 2008 17:28:38 +0100

Hello Marc, hello Bill,

If it is right what I understand, than it is the only job of the
MessageOutputWriter to serialize the given Object. The same should be
for the StreamingOutput: Read all necessary data first in the resource
method and than serialize them. Where should there be a WebAppException?

If I have to send the response, than I first wrote the status and then
the header to the OutputStream and then call the
MessageBodyWriter.writeTo(......) or StreamingOutput.write(.). How
should I then handle an Exception?
This proposal requires, that the OutputStream (to the i-net) ist wrapped
and the first call of the wrapper OutputStream write the status and the
header first. What a bad design, IMO.


Marc Hadley schrieb:
> On Mar 12, 2008, at 7:56 PM, Bill Burke wrote:
>> Ok, I believe there is a problem with the streamed output model.
>> Let's go back to the Ajax Polling usecase where the client does a GET
>> and waits and waits and waits for a response. What if we want to
>> allow the client to specify a timeout? The StreamedOutput interface
>> requires a commit of the status and headers, correct? So, in our
>> background asynch writes, there would be no way to timeout and send
>> back the appropriate HTTP Response code.
>> Are you following me?
>> I guess a solution to this would be to not commit until something is
>> written to the OutputStream and allow a WebApplicationException to be
>> thrown. The same is already done for MessageBodyWriter's correct?
> Correct.
> So a MessageBodyWriter or a StreamedOutput could throw a
> WebApplicationException before writing to the stream and that would
> cause the HTTP response status to be set and normal exception handling
> to take over. Sounds reasonable to me - we have an issue to sort out
> exception handling, i'll be focussing on that once we get the current
> batch of issues resolved.
> Marc.