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
Produce/ConsumeMime...
> (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.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109