Re: JSR311: Response isn't adequate

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Thu, 28 Feb 2008 10:35:39 -0500

A few points on OutputStream access:

- We had such a capability in the initial API proposal but it was
removed as being too low level and covering much of the API space
already covered by the servlet API. See:

- As already mentioned you can get at an OutputStream in a
MessageBodyWriter provided you are able to wrap the necessary
resources in a type that the MessageBodyWriter can operate on.

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


On Feb 26, 2008, at 12:48 PM, Bill Burke wrote:

> 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?
> Like:
> @ConsumeMime("multipart/mixed")
> @PUT
> public void upload(List<JPEG> images);
> @ProduceMime("multipart/mixed")
> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.