On Mar 12, 2008, at 7:32 PM, Bill Burke wrote:
> Looks like I'm outvoted...
>
> So what does it look like?
>
> @GET
> public String get() {
>
> StreamedOutput output = new StreamedOutput() {
> public void write(OutputStream stream) {
> // do some stuff
> }
> };
>
> return Response.ok(output).build();
> }
>
Yes, except get() returns Response. In the above case you could also
return StreamedOutput directly since 200 is the default status code
when there's an entity body.
Marc.
> Ryan McDonough wrote:
>> +1 here as well.
>> An inner class is only so awkward and I can certainly live with that.
>> Ryan-
>> On 3/12/08, *Marc Hadley* <Marc.Hadley_at_sun.com <mailto:Marc.Hadley_at_sun.com
>> >> wrote:
>> On Mar 12, 2008, at 9:53 AM, Bill Burke wrote:
>> > i'd rather have both. Again, it just seems very awkward to
>> have to
>> > write an inner class or a separate class just to do
>> streaming. So
>> > far, JAX-RS has been pretty elegant.
>> >
>> I think the solution described below is more elegant than the
>> previous
>> one, it preserves the simple model where you return the HTTP
>> response
>> from a resource method and does away with a bunch of additional
>> rules
>> like requiring a void return when using the injected output stream
>> accessor type. The other solution introduces a completely new
>> paradigm
>> for creating a response.
>> Marc.
>> > Marc Hadley wrote:
>> >> Not wishing to stifle an interesting debate but I'd like to
>> move
>> >> towards a conclusion ;-). Can we close this issue with the
>> proposal
>> >> below ? It gets Bill an OutputStream that can be used without
>> >> having to implement a MessageBodyWriter while not tying up a
>> >> service thread as desired by Jerome and Stephan. Seems like a
>> >> reasonable compromise to me.
>> >> Marc.
>> >> On Mar 10, 2008, at 3:59 PM, Marc Hadley wrote:
>> >>>
>> >>> public interface StreamedOutput {
>> >>> void write(OutputStream o);
>> >>> }
>> >>>
>> >>> Which can be returned when you want to do streaming - the
>> spec
>> >>> would require implementations to support this type.
>> >> ---
>> >> Marc Hadley <marc.hadley at sun.com <http://sun.com>>
>> >> CTO Office, Sun Microsystems.
>> >>
>>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
>> >> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>> <mailto:dev-help_at_jsr311.dev.java.net>
>> >
>> > --
>> > Bill Burke
>> > JBoss, a division of Red Hat
>> > http://bill.burkecentral.com
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
>> > For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>> <mailto:dev-help_at_jsr311.dev.java.net>
>> >
>> ---
>> Marc Hadley <marc.hadley at sun.com <http://sun.com>>
>> CTO Office, Sun Microsystems.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>> <mailto:dev-help_at_jsr311.dev.java.net>
>> --
>> Ryan J. McDonough
>> http://www.damnhandy.com
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> 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.