Re: JSR311: Response isn't adequate

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 26 Feb 2008 17:28:36 +0100

Bill Burke wrote:
>> 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.

I was assuming the implementation of InputStream.close would do that.

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

The information returned from Response.getMetadata can be post-processed
once it is passed back to the runtime, or an optimal method can be
supported on the Response implementation provided by the runtime. I
think we should clear up the JavaDoc around when conversion may occur.

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

Are you referring to reusing the Response for headers of a MIME part?

> 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 want to experiment with JavaBeans and multipart/form using the
JavaMail API, but time is not on my side!

>> [*] 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.

Me neither, the @Path might not make any sense, nor the

> (Maybe that's why you
> didn't want to introduce anything HTTP specific?)

Sort of :-) my preference was to stick closer to HTTP but IIRC the
consensus was more to an abstraction.


| ? + ? = To question
    Paul Sandoz