users@jersey.java.net

Re: [Jersey] Looking for "best practices"

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 19 Jan 2010 11:34:15 +0000

On Jan 19, 2010, at 11:27 AM, Felipe Gaúcho wrote:

> humm.. no problem to cache server resources (memcache) for performance
> reasons.. and other tricks...., but just keep in mind that in REST you
> should never cache "http responses payload" in the server side.... it
> always should be cached in the client side (one of principles of
> rest).....
>

It can also be cached by a web proxy instead, which can simplify the
client.

I suppose it depends on what you mean by "cache". Server's can also
"retain" stuff in memory. It all depends on the application and the
application should be careful to declare the cache control header
appropriately.

Paul.

>
> On Tue, Jan 19, 2010 at 12:07 PM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>>
>> On Jan 14, 2010, at 3:16 PM, Comerford, Sean wrote:
>>
>> So I’m slowly working through a prototype application and have a
>> couple of
>> high level newbie questions.
>>
>> Q1) How to best provide a “light” XML/JSON feed?
>>
>> Initial testing has shown that (due to performance considerations)
>> I need to
>> slim down the markup I’m outputting. Un/marshalling costs are just
>> too high
>> if I output all the fields we have in our POJOs.
>>
>> I can easily accomplish that by marking a lot of stuff
>> @XmlTransient so it’s
>> omitted.
>>
>> But the problem with that is there are SOME cases where I really do
>> need
>> want those fields in the markup.
>>
>> So what I’m looking to do is develop a “light” and “full” version
>> of my
>> output. Short of basic coding conventions (i.e. gving multiple
>> classes
>> representing the same underlying data but with differing JAXB
>> annotations),
>> does jersey or JAXB provide anything in this respect?
>>
>>
>> No, currently the application developer has to do that when using
>> JAXB.
>>
>> Creating resource “views” is one possible solution I guess but I’m
>> not sure
>> that feels right and it certainly loses some of the “automagic”
>> benefit of
>> the Jersey+JAXB framework but perhaps I’m missing something.
>>
>> Q2) Controlling the Jersey life cycle... I could have sworn I saw
>> an example
>> of this but can’t seem to find now. Let’s say for the sake of
>> argument I
>> want to marshal my Java objects to XML myself (maybe to cache the
>> JAXB
>> generated markup) and have my @GET method return that instead of a
>> JAXB
>> annotated POJO instance.... How do I do that / can someone point me
>> to an
>> example?
>>
>>
>> You could make the resource class a singleton and cache in a field
>> of byte[]
>> of the serialization on the first request.
>> @Singleton
>> public class MyResource {
>> byte[] xyz;
>> @GET
>> public byte[] get() {
>> synchronized(this) {
>> if (xyz == null) {
>> // cache
>> }
>> return xyz;
>> }
>> }
>> }
>>
>> I think there may be more general solutions using etags and ehcache
>> or using
>> a web proxy with appropriate cache-control headers.
>> Paul.
>
>
>
> --
> ------------------------------------------
> Felipe Gaúcho
> 10+ Java Programmer
> CEJUG Senior Advisor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>