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.
On Feb 29, 2008, at 5:53 PM, Bill Burke wrote:
> I just don't want JAX-RS to be solely a high-level API. Its already
> so much more elegant that servlets even if you're only using it for
> low level streaming and not using any providers.
>
> Larry Cable wrote:
>> Err ... good reposte ... I will have to cogitate upon that for a
>> moment, but I think in general the answer is
>> "yes" ... although just adding such an ability would certainly
>> improve things to the current state of the art
>> in Servlet 2.x ... which I think is a minimal requirement
>> - Larry
>> ------------------------------------------------------------------------
>> *From:* Marc Hadley
>> *Sent:* Fri 2/29/2008 12:06 PM
>> *To:* dev_at_jsr311.dev.java.net
>> *Subject:* Re: JSR311: Response isn't adequate
>> I think I understand now. The issue isn't with the Provider model
>> its a more general problem. Just adding the ability to get at an
>> OutputStream (the same one you get in an entity provider) from a
>> resource class won't fix anything. Right ?
>> Marc.
>> On Feb 29, 2008, at 2:26 PM, Larry Cable wrote:
>>> I agree with Bill, both Servlet *and* this JSR require a
>>> mechanism to allow streaming/chunking to the
>>> response output stream ... best to fix this in 1.0 as fixing it
>>> in 3.0 (ala Servlet) is a bit like making
>>> unthreaded, non reentrant code in the C locale, MT-hot and I18N-
>>> ized at the same time!
>>>
>>> :)
>>>
>>> - Larry
>>>
>>> From: Bill Burke
>>> Sent: Fri 2/29/2008 10:20 AM
>>> To: dev_at_jsr311.dev.java.net
>>> Subject: Re: JSR311: Response isn't adequate
>>>
>>> Marc Hadley wrote:
>>> > On Feb 28, 2008, at 12:10 PM, Bill Burke wrote:
>>> >>
>>> >> And I've already told you that this just not cut it for
>>> specific use
>>> >> cases (Blobs). It is going to make EJB integration(really
>>> anybody
>>> >> that uses JTA) unusable in those cases. I don't think Lobs are
>>> an
>>> >> unreasonable use case to support.
>>> >>
>>> >>> - In a servlet container you can inject HttpServletResponse
>>> and use
>>> >>> the OutputStream from that but you'll have to set any headers
>>> >>> yourself before you commence writing.
>>> >>
>>> >> So, anything that doesn't fit the @Provider model, we'll have to
>>> >> escape to Servlet API or worse, have our own vendor specific
>>> extension
>>> >> for? Hmmmm...All because we can't inject an OutputStream.
>>> >>
>>> > I'm not I understand why blobs don't fit the provider model ? If
>>> the
>>> > provider runs in the same connection+transaction scope as the
>>> resource
>>> > method and can be injected with all the same stuff what doesn't
>>> work ?
>>> > Sorry if I'm being dense here.
>>> >
>>>
>>>
>>> That's the thing, the provider has to run in the same transaction
>>> scope
>>> as the resource. Every container I know that does transactions
>>> usually
>>> ends the transaction before a response is sent back to the client.
>>> (a.k.a EJB TransAttribute.REQUIRED). You basically wouldn't be
>>> able to
>>> use container managed transactions. Are you following me? I
>>> don't know
>>> if I'm being clear.
>>>
>>>
>>> > Injecting an OutputStream is only half the work, if you still
>>> want to be
>>> > able to use Response to specify headers then you'd either have
>>> to call
>>> > that first and somehow pass that to the runtime then start
>>> writing to
>>> > the output stream or we'd have to buffer the output waiting for
>>> the
>>> > method to complete and return the response. Again, sorry if I
>>> missed
>>> > something, I'm still catching up from a few days vacation.
>>> >
>>>
>>> Don't want the buffering. That could be done in the current
>>> model. I
>>> want the ability to stream LOBs and again, some DBs require a
>>> connection
>>> to be open while you're reading a LOB.
>>>
>>> --
>>> 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
>>>
>>>
>>> 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.
>> ---
>> 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.
>
> --
> 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.