dev@jsr311.java.net

Re: JSR311: Problem with StreamedOutput model

From: Stephan Koops <Stephan.Koops_at_web.de>
Date: Fri, 14 Mar 2008 12:09:00 +0100

If we build a GUI application, we partition the responsibilities to MVC.
We all know this model. Nobody who wants to build a well designed
application allows the model to change the controller or the GUI. This
is known in computer sience since since round about 25 years. A good
designer calls a GUI framework, that promote to break the MVC model, a
bad designed framework. Right?

Also here: It is not good to allow the MessageBODYwriter (the model of
the MVC comparisaon) to alter the HTTP headers (could be compared with
the controller of MVC).

For the MessageBodyWriter I can imagine use cases where it is useful to
allow this, but at the expenses of the design. But where is it needed in
the StreamingOutput? All what I can do in the StreamingOutput.write(..),
what is done before starting the writing on the output, could be done
ahead in the resource method, by moving it from the beginning of the
write method ahead the creation of it.

best regards
   Stephan

Marc Hadley schrieb:
> 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.