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
>