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:
https://jsr311.dev.java.net/source/browse/jsr311/trunk/src/jsr311-api/src/javax/ws/rs/core/WebResource.java?rev=7&view=markup
https://jsr311.dev.java.net/source/browse/jsr311/trunk/src/jsr311-api/src/javax/ws/rs/core/HttpResponseContext.java?rev=7&view=markup
- 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.
Marc.
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
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.