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