Re: JSR311: Problem with StreamedOutput model

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Thu, 13 Mar 2008 13:01:01 -0400

On Mar 13, 2008, at 12:28 PM, Stephan Koops wrote:
> 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.
The OutputStream needs to be wrapped since the MessageBodyWriter can
modify the HTTP headers before it starts writing to the output stream.
I don't see what's wrong with that.


> 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.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.