Re: JSR311: Response isn't adequate

From: Bill Burke <>
Date: Tue, 26 Feb 2008 12:48:21 -0500

Paul Sandoz wrote:
> 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.

That's a hack, plus, doesn't solve the problem of a connection that's
controlled by a transaction. Most app server stacks have a layered
approach to design. Receive request, dispatch it to container,
transaction boundery, process request, close transaction, return to
network transport, send response.

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


public void upload(List<JPEG> images);

List<JPEG> getImages();

One provider needs to know how to understand multipart, another knows
how to read/write JPEG.

That's a static example. Then you might have a dynamic example where the
Resource doesn't know the media types it wants to marshal:

List<Object> getImages() {

    Multipart list = ...;

    list.add(new JPEG());
    list.add("Hello World");
    list.add(new GIF());

    return list;

The providers would need a way to recursively call themselves.

Then you have the BLOB example I gave before with a Multipart request.

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

IMO, we have to get @Providers right and that includes funky things like
Multipart. I don't care if the specification goes into corner cases, but
we need an extensibility API that gives us enough power to add things.

>> 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
> Produce/ConsumeMime...

Produce/Consume does. HeaderParam. Maybe that's it?

Bill Burke
JBoss, a division of Red Hat