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.
>
> 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: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.