users@jersey.java.net

Re: [Jersey] NPE at AbstractMessageReaderWriterProvider.readFromAsString()

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 11 Dec 2008 11:00:49 +0100

On Dec 11, 2008, at 10:34 AM, Gili wrote:

>
>
> Paul Sandoz wrote:
>>
>> For the case you are describing is it not just as easy for the
>> application to retain the object returned from the getEntity?
>>
>
> In my particular case, yes, simply because it turns out that my code
> wasn't
> supposed to read the entity twice (this was caused by a bug). But I
> can see
> the need for this kind of code:
>
> public isPoem(ClientResponse response)
> {
> if (response.getEntity(String.class).equals("my poem"))
> return true;
> else
> return super.isPoem(response);
> }
>
> you can then imagine super.isPoem() reads the entity and parses the
> content
> differently. In short, anyone wishing to implement the
> chain-of-responsibility design pattern will be hard-pressed to do so.
> Ideally they want to pass the ClientResponse around, not a
> ClientResponse
> with an external copy of the Entity. Also, from an end-user
> perspective
> they'd prefer for you to handle all the complexity of handling the
> bytes and
> handling type conversion instead. For example, right now users can
> invoke
> getEntity(String.class), getEntity(Foo.class) and conversions will be
> handled internally. Your suggestion, if I understand you correctly,
> would
> push the conversions onto the end-users.

I was assuming there would be only one conversion to a particular Java
type.


> They would have to retrieve the
> byte[] the first time, pass it around alongside the ClientResponse and
> handle conversions themselves.
>

In such cases i think the best solution is to provide a wrapping class
that implements ClientResponse thats performs buffering.


> With respect to performance I think we also need to take into
> consideration
> that we're talking about client-side code here. It is understandable
> that
> servers try to avoid retaining client state whenever possible (to
> improve
> scalability) but client-side code doesn't have the same problem:
> you're
> retaining your own data, not the data belonging to 100s of other
> clients.
> Furthermore, even if we buffer this data it is still very short-
> lived. I
> argue that whatever "data churn" this creates will be well worth the
> ease-of-use benefits to the resulting API.
>

Servers can be clients too. I expect to see a lot more of this as
service composition using the REST style becomes a more popular way of
building enterprise systems. The ability to interleave processing with
waiting on IO when managing many request using a thread pooling
strategy allows one to scale much better than if complete buffering
then processing. This becomes more important for chips with many cores
and hardware threads.

As i said i think the right approach to deal with this properly is for
the client to utilize an HTTP caching strategy.

Paul.