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