users@jersey.java.net

Re: [Jersey] Looking for "best practices"

From: Felipe Gaúcho <fgaucho_at_gmail.com>
Date: Tue, 19 Jan 2010 12:39:59 +0100

One of the top items in my Glassfish whishlist is a set of default
HTTP filters for leveraging the basic HTTP tags like ETAG or Expire
Date

it is not hard to add these filters to every application, but a button
on the Glassfish admin console saying "enable default tuning for
web-apps" would be a lovely thing :) eheh

On Tue, Jan 19, 2010 at 12:34 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>



-- 
------------------------------------------
   Felipe Gaúcho
   10+ Java Programmer
   CEJUG Senior Advisor