On Mar 5, 2008, at 5:16 PM, Larry Cable wrote:
> I believe that given the purpose of obtaining the output stream it
> would normally be appropriate to flush the entity rather than
> throw ... what would you anticipate a users code would do in the
> catch block?
>
Well, depending on your viewpoint the exception should never really
happen. If you want the runtime to write an entity then you can just
return it from the method instead. Having the getOutputStream method
write an entity present in the Response just gives you two ways to
accomplish the same thing which seems redundant.
Marc.
>
> ________________________________
>
> From: Marc Hadley [mailto:Marc.Hadley_at_Sun.COM]
> Sent: Wed 3/5/2008 11:03 AM
> To: dev_at_jsr311.dev.java.net
> Subject: Re: JSR311: Response isn't adequate
>
>
>
> On Mar 5, 2008, at 1:12 PM, Marc Hadley wrote:
>
>> On Mar 3, 2008, at 1:20 PM, Stephan Koops wrote:
>>>
>>> I think, it's good, to use getOutputStream(Result), because this
>>> make it clearer, what is meant with the method. It could throw an
>>> IllegalArgumentException, if an entity is set.
>>> When using read only interfaces, very often we accpet a
>>> UnsupportedOperationException, why no here an
>>> IllegalArgumentException?
>>>
>> I guess we could do that but it might be a bit counter-intuitive for
>> users. The alternative would be to write any entity and then return
>> the output stream. The suggested method signature was intended to
>> avoid this issue but I agree that:
>>
>> Response r = Response.created("someuri").type("sometype").build();
>> OutputStream os = so.getOutputStream(r);
>>
>> is neater than:
>>
>> Response r = Response.created("someuri").type("sometype").build();
>> OutputStream os = so.getOutputStream(r.getStatus(), r.getMetadata());
>>
>> What do others think, do you prefer getOutputStream(Response) or
>> getOutputStream(int, MultivaluedMap<String, Object>).
>
> The following should have read: if you prefer the former, do you
> prefer throwing an IllegalArgumentException if Response has an entity
> or should the method write the entity and return a stream positioned
> at the end of it.
>
> Marc.
>
>> If the latter do you prefer throwing an IllegalArgumentException is
>> Response has an entity or should the method write the entity and
>> return a stream positioned at the end of it.
>>
>> Marc.
>>
>>>
>>> Marc Hadley schrieb:
>>>> How does the following sound:
>>>>
>>>> public interface StreamingOutput {
>>>> OutputStream getOutputStream(int status, MultivaluedMap<String,
>>>> Object> metadata);
>>>> }
>>>>
>>>> A resource method can have a parameter of the above type but, if
>>>> so, it MUST have a void return type. You get an output stream by
>>>> passing in the desired status code and metadata which you can get
>>>> from a Response instance (or create yourself). I don't want
>>>> getOutputStream(Response) since that brings up questions about
>>>> what to do if the response contains an entity and I don't really
>>>> like any of the answers to that question. Calling getOutputStream
>>>> more than once isn't allowed.
>>>>
>>>> An example of usage:
>>>>
>>>> @GET
>>>> public void getData(StreamingOutput so) {
>>>> Response r = Response.created("someuri").type("sometype").build();
>>>> OuptutStream os = so.getOutputStream(r.getStatus(),
>>>> r.getMetadata());
>>>> os.write(...)
>>>> }
>>>>
>>>> We'd still use @ProduceMime to choose a method to call and to
>>>> default the content type if not explicitly set.
>>>>
>>>> I had a failure of imagination when coming up with the interface
>>>> and method names, if you have better ideas I'd like to hear them.
>>>>
>>>> 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.
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
>
>
>
> Notice: This email message, together with any attachments, may
> contain information of BEA Systems, Inc., its subsidiaries and
> affiliated entities, that may be confidential, proprietary,
> copyrighted and/or legally privileged, and is intended solely for
> the use of the individual or entity named in this message. If you
> are not the intended recipient, and have received this message in
> error, please immediately return this by email and then delete it.
>
> ---------------------------------------------------------------------
> 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.