Jerome Louvel wrote:
> Hi all,
>
> Let's me jump in the middle of the discussion. I agree that the support for
> large bodies is important for JAX-RS and that there needs to be a way to
> stream some dynamic content (blob or anything else).
>
> I understand the issue with opened transactions but I don't think that the
> idea to give a direct blocking access to the outputstream is good. It shifts
> a problem coming from the EJB transaction model into the JAX-RS API.
>
> Also, it will prevent optimal usage of NIO in those cases as it will require
> one thread is blocked per request, until the response is fully written.
>
Do the message body readers/writers require writeTo/readFrom methods for
NIO constructs as well?
> It is more efficient to let the HTTP layer pull the content as needed. Let's
> try to not reproduce the same Servlet API design issue again. For background
> info, see: http://blogs.webtide.com/gregw/2004/09/24/1096051860000.html
>
I very much agree with this. The link is most excellent at explaining
the issues.
> When we designed the Restlet API, we were extremely careful about this
> aspect. This allows us to have a fully asynchronous processing model on the
> server-side as well as on the client-side. See:
> http://www.restlet.org/about/introduction
>
> I think that the transaction should be left open by the EJB container (using
> the deployment descriptor as explained by Larry I think). The message body
> writer could perfectly manually close the transaction once the writing is
> done, either by overriding the close() method as suggested by Paul or by
> overriding a new release() method on the MessageBodyWriter interface.
>
We need closures :-)
Paul.
> Best regards,
> Jerome Louvel
> --
> Noelios Consulting
> http://www.noelios.com
>
>> -----Message d'origine-----
>> De : Larry Cable [mailto:lcable_at_bea.com]
>> Envoyé : vendredi 29 février 2008 20:26
>> À : dev_at_jsr311.dev.java.net
>> Objet : RE: JSR311: Response isn't adequate
>>
>> 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.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109