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