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