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.