On Jan 29, 2009, at 2:13 PM, Reto Bachmann-Gmür wrote:
>
> The API doc says that the method returns -1 if the length /cannot/ be
> determined in advanced. As for normal content the length can always be
> determined I thought that only for streaming sources or
> comet-applications the method would have to return -1. Without
> considering the possibility of implementations doing some buffering to
> determine the length or doing chunked encoding, I assumed -1 would
> render Keep-Alive impossible.
>
I think going for chunked encoding when -1 is returned would be fine
and would still permit keep-alive.
> Would it make sense for the writer to tell the implementation that the
> implementation should determine the length itself, that is the
> response
> is finite and short and no purposeful interruption (such as with
> server-push) will happen when writing to the stream?
>
I guess that could avoid some unnecessary chunking but I don't know if
that would make much difference performance-wise.
Marc.
>
>
> Paul Sandoz said the following on 01/29/2009 01:05 PM:
>> Hi Reto,
>>
>> My approach has been to only implement get size iff it is known in
>> advanced (e.g. File size). I consider it more of a hint to the HTTP
>> container to know whether it can use a Content-Length with that value
>> instead of:
>>
>> 1) using chunked transfer encoding;
>>
>> 2) buffering the content to determine the length; or
>>
>> 3) closing the connection after the response entity has been
>> written.
>>
>> I think the HTTP container should determine the best strategy of one
>> of the three above and the writers do not need to be involved in such
>> details.
>>
>> If getSize returns a value > -1 then that value should be equal to
>> the
>> value that is number of bytes that are written to the OutputStream of
>> the writeTo method for the same parameter values passed to both
>> methods.
>>
>> Paul.
>>
>> On Jan 29, 2009, at 9:41 AM, Reto Bachmann-Gmür wrote:
>>
>>> Hello
>>>
>>> I'm wondering what the best practice to write MBWs is. In my
>>> experience
>>> the getSize and the writeTo method often have very similar code,
>>> or the
>>> getSize-method looks similar to this:
>>>
>>> @Override
>>> public long getSize(GraphNode node, Class<?> clazz, Type t,
>>> Annotation[] as,
>>> MediaType m) {
>>> ByteArrayOutputStream baos = new ByteArrayOutputStream();
>>> try {
>>> writeTo(node, clazz, t, as, m, null, baos);
>>> } catch (IOException ex) {
>>> throw new RuntimeException(ex);
>>> } catch (WebApplicationException ex) {
>>> throw new RuntimeException(ex);
>>> }
>>> return baos.size();
>>> }
>>>
>>> One optimization might be to cache the resulting object- bytes
>>> mapping
>>> (in a ThreadLocal weak reference of a WeakHashMap) so that when the
>>> implementation invokes writeTo, the already computed bytes can be
>>> written to the OutputStream.
>>>
>>> Another approach could be to return an estimate of the size or -1
>>> in the
>>> getSize method, and set the exact Content-Length to the headers-
>>> map when
>>> writeTo is invoked.
>>>
>>> Another issue is when the rendering of the object could change
>>> between
>>> invocation of getSize and writeTo. The class GraphNode represents
>>> a node
>>> in a graph (which is occasionally modified), the writers for
>>> different
>>> media-types expand the neighborhood of the node to different
>>> depths so
>>> that it would be awkward to do this expansion in the resource
>>> method and
>>> return a value-object. I think in such a scenario the writeTo method
>>> must either write the bytes pre-computed on invocation of getSize or
>>> (re)set the Content-Length header.
>>>
>>> Cheers,
>>> Reto
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.