On Dec 10, 2008, at 6:08 PM, Gili wrote:
>
> I believe that reading the entity multiple times is a
> reasonable
> use-case, especially if you're passing the ClientResponse object
> around.
> Furthermore, I'm not sure I see what the problem is with caching this
> data.
Caching is different from buffering :-) the former, a client side in-
memory cache, would IMHO be a better general solution to the problem
and the client just keeps making requests.
For the case you are describing is it not just as easy for the
application to retain the object returned from the getEntity?
> Memory consumption doesn't go up as you're simply shifting the
> bytes from one structure into another...
>
There is no point buffering something unless you really need to do it
because otherwise you just increase the temporary churn of resources
which for large quantities of information, or when scaling out for
many requests, may have a noticeable effect.
We could supply a wrapper class BufferedClientResponse that one can
use to buffer things (and reset things):
ClientResponse cr = ...
BufferedClientResponse bcr = new BufferedClientResponse(cr);
You could also write your own wrapper that does something smarter like
keep a reference to the deserialized instance so if you ask for the
same type as previously you do not need to deserialize again.
Incidentally a developer experimented with the client API caching JAXB
objects in memory (using a filter and obeying HTTP caching rules) so
that JAXB unmarshalling did not have to be performed all the time for
cached information.
Paul.
> Gili
>
> Paul Sandoz (via Nabble) wrote:
>
> > HI Gili,
> >
> > Thanks for reporting this.
> >
> > I think the solution should be not to set the input stream to null
> but
> > to leave it as is and then let any exception flow through or
> return of
> > a null value if all the bytes in the input stream are consumed. That
> > way it would be possible to call it more than once if supported for
> > deserialization of certain java types that consume only as much as
> > they require. We should JavaDoc the restrictions on the invocation
> of
> > getEntity.
> >
> > Paul.
> >
> > On Dec 10, 2008, at 6:41 AM, Gili wrote:
> >
> > >
> > > I figured it out. It looks like I can invoke
> > > ClientResponse.getEntity(String.class) once, but if I invoke it
> twice
> > > consecutively this exception is thrown. This is caused by the
> fact
> > > that
> > > URLConnectionClientHandler.java line 160 sets "in" (the
> InputStream)
> > > to
> > > null. I posted this bug report:
> > > https://jersey.dev.java.net/issues/show_bug.cgi?id=159
> > >
> > > I pointed out one possible fix though I will be the first to
> admit
> > > that it
> > > is a little hairy. Hopefully you will find a cleaner solution.
> > >
> > > Thank you,
> > > Gili
> > >
> > >
> > > Gili wrote:
> > >>
> > >> Hi Paul,
> > >>
> > >> I get this exception in jersey-client when I invoke
> > >> ClientResponse.getEntity(String.class):
> > >>
> > >> java.lang.NullPointerException
> > >> at java.io.Reader.<init>(Reader.java:61)
> > >> at
> java.io.InputStreamReader.<init>(InputStreamReader.java:96)
> > >> at
> > >> com
> > >> .sun
> > >> .jersey
> > >> .core
> > >> .provider
> > >> .AbstractMessageReaderWriterProvider
> > >> .readFromAsString(AbstractMessageReaderWriterProvider.java:85)
> > >> at
> > >> com
> > >> .sun
> > >> .jersey
> > >> .core
> >
> >> .impl.provider.entity.StringProvider.readFrom(StringProvider.java:
> 70)
> > >> at
> > >> com
> > >> .sun
> > >> .jersey
> > >> .core
> >
> >> .impl.provider.entity.StringProvider.readFrom(StringProvider.java:
> 55)
> > >> at
> > >>
> com.sun.jersey.client.impl.urlconnection.URLConnectionClientHandler
> > >>
> $URLConnectionResponse.getEntity(URLConnectionClientHandler.java:156)
> > >> at
> > >>
> com.sun.jersey.client.impl.urlconnection.URLConnectionClientHandler
> > >>
> $URLConnectionResponse.getEntity(URLConnectionClientHandler.java:138)
> > >> at
> > >> adcaster.shared.persistence.Resources
> > >> $IOExceptionBuilder.cause(Resources.java:192)
> > >>
> > >>
> > >> Please confirm.
> > >>
> > >> Thanks,
> > >> Gili
> > >>
> > >
> > > --
> > > View this message in context:
> > http://n2.nabble.com/NPE-at-AbstractMessageReaderWriterProvider.readFromAsString%28%29-tp1636314p1637389.html
> > > Sent from the Jersey mailing list archive at Nabble.com.
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@...
> > <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=1638000&i=0>
> > > For additional commands, e-mail: users-help@...
> > <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=1638000&i=1>
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=1638000&i=2>
> > For additional commands, e-mail: users-help@...
> > <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=1638000&i=3>
> >
> >
> >
> >
> ------------------------------------------------------------------------
> > This email is a reply to your post @
> > http://n2.nabble.com/NPE-at-AbstractMessageReaderWriterProvider.readFromAsString%28%29-tp1636314p1638000.html
> > You can reply by email or by visting the link above.
> >
>
> View this message in context: Re: [Jersey] NPE at
> AbstractMessageReaderWriterProvider.readFromAsString()
> Sent from the Jersey mailing list archive at Nabble.com.