dev@jsr311.java.net

RE: JSR311: Response isn't adequate

From: Larry Cable <lcable_at_bea.com>
Date: Wed, 5 Mar 2008 14:16:06 -0800

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?
 
- Larry

________________________________

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.