Re: JSR311: Response isn't adequate

From: Bill Burke <>
Date: Thu, 06 Mar 2008 08:53:15 -0500

Jerome Louvel wrote:
> 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:
> 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:

You're gonna have to explain to me or link examples on how a
"content-based" api can do streaming and not have to hold large content
in memory. Is it JAX-RS's MessageBodyReader/Writer model except with
NIO constructs?

You'll also have to explain to me why we couldn't just inject NIO
interfaces into the component.

> I think that the transaction should be left open by the EJB container (using
> the deployment descriptor as explained by Larry I think).

This is a proprietary API.

> 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.

So, instead of a transaction, let's consider what we have to do with
regular JDBC.

We'd have to write a specific "Content Handler" that handled streaming
the blob and closing/committing the JDBC connection and register it with
the JAX-RS at boot/config time. All just to stream some data?

This is the real reason I want a streaming API. JAX-RS is a web service
API not necessarily solely a content API. I don't want to have to do
convoluted shit just to be able to do streaming. What's available to
the "content API" a.k.a. MessageBodyReader/Writers, should be available
to the component. Sometimes all this abstraction is just complete overkill.


Bill Burke
JBoss, a division of Red Hat