Re: JSR311: Response isn't adequate

From: Bill Burke <>
Date: Tue, 26 Feb 2008 10:04:54 -0500

Paul Sandoz wrote:
> Bill Burke wrote:
>> Paul Sandoz wrote:
>>> Bill Burke wrote:
>>>> It seems we have no access to an OutputStream. I can see the need
>>>> for wanting to stream back to the client a DB's Blob or Clob.
>>> Two workarounds:
>>> - develop a message body writer for the Blob/Clob; or
>>> - if the Blob/Clob is accessed as an InputStream one can return that.
>> This is impossible as you need to have the JDBC connection/resultset
>> open IIRC.
> I suppose the InputStream.close() can do this. The message body writer
> for InputStream should close the stream after all bytes have been
> written, or an exception occurs (we need to specify that behaviour). But
> i can see why this can be error prone...

Sometimes, depending on the DB, you must interact with the BLob within a
non-closed ResultSet/Connection. So, not only do you have to close the
stream, you also have to close the result set, and connection. This is
especially problematic if your connections are being managed by a pool
and associated with a transaction.

> It would be nice if we could still use the response building mechanism.
> Perhaps something like the following that extends OutputStream:

I never really liked the current Response building mechanism. Already
because location() is based on BaseURI, this requires tunneling of
request information through a ThreadLocal. This reliance on static
factory methods to create a ResponseBuilder also smells too.

Then there is the problem of Multipart responses, which is mostly a
@Provider problem, but which possibly bleeds into the Response
abstraction as well. Especially with the BLOB case.

I guess what I'm saying is that I wish Response was an interface and was
injected as a parameter. I'm also saying that Jersey, JBoss, and
whoever else is implementing JAX-RS should probably do some Multipart
prototyping so that we can flush out Response and @Provider abstractions
a bit more.

> [*] i really do wish there were a set of reusable HTTP request/response
> interfaces that could be shared across HTTP frameworks.

Not sure this Response abstraction needs to be tied to HTTP
request/response interfaces. I don't know Mail protocols very well, but
it seems JAX-RS could be used there a lot too. (Maybe that's why you
didn't want to introduce anything HTTP specific?)

Bill Burke
JBoss, a division of Red Hat