users@jersey.java.net

Re: [Jersey] Looking for "best practices"

From: Felipe Gaúcho <fgaucho_at_gmail.com>
Date: Tue, 19 Jan 2010 14:24:57 +0100

That's a chance to push Glassfish ahead of its competitors.. :)

* just offer fast server is not enough anymore.... it is good, but the
developers are looking for "Java EE amenities".. :) eheh

* I will talk with Alexis next week during the Jfokus.. let's see..
Jersey + Glassfish is a powerful combination :)

On Tue, Jan 19, 2010 at 2:22 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> On Jan 19, 2010, at 11:39 AM, Felipe Gaúcho wrote:
>
>> 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
>>
>
> Yes, that would work for "shallow" etags, where the work still has to be
> performed to obtain a serialization of the representation such that the ETag
> (something like an MD5 checksum) can be calculated from the serialization.
> Shallow etags can save of bandwidth but not server-side resources.
>
> Then there are "deep" etags that require more involvement with the
> application. I believe we could do something interesting with Jersey (and
> perhaps ehcache) to support deep etags. Deep etags can save on bandwidth and
> server-side resources.
>
> Paul.
>
>
>> 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
>>
>> ---------------------------------------------------------------------
>> 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