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.
>>>>
>>>
>>> https://jsr311.dev.java.net/issues/show_bug.cgi?id=6
>>>
>>> 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
http://bill.burkecentral.com