users@glassfish.java.net

Re: setCacheControl doesn't work - Rails app deployed on Glassfish v3

From: Vivek Pandey <Vivek.Pandey_at_Sun.COM>
Date: Sun, 11 Jan 2009 09:26:48 -0800

Hi mileoresko,

Yes, this is an issue inside grizzly-jruby extension. This will be fixed
on the glassfish v3 trunk. Although it needs to be discussed how we need
to fix it since on trunk we have redesigned to support ruby frameworks
to Rack spec (Rack adapters) and the caching is handled there.

Regarding patch for GlassFish v3 Prelude, we provide patches for v3
prelude only for subscription customers. I don't know if you have
subscription of glassfish v3 prelude, if not then you would need to
wait till the fix happen on the v3 trunk.

Other option is that you can use some reverse proxy to serve the static
content thru some light weight web servers. I believe most of such
reverse proxy supports such cache control headers.

The issue 7021 is updated accordingly.

-vivek.

Jeanfrancois Arcand wrote:
> Salut,
>
> glassfish_at_javadesktop.org wrote:
>> Hi All,
>>
>> We have a problem with cache control on our glassfish app server.
>> We are using Sun Glassfish Enterprise Server v3 prelude b28c. We have
>> developed the web application with jRuby 1.1.4 and Rails 2.1.2, and
>> deployed the application
>> to the Sun Glassfish Server as a folder (not a war file)
>> In the domain.xml file in the Sun Glassfish Server we set the
>> setCacheControl property to a max-age value of 300 because we want
>> the static content to be kept in the browser cache for 5 minutes
>> (testing value).
>>
>> <virtual-server ... >
>> ...
>> <property name="setCacheControl" value="max-age=300" />
>> </virtual-server>
>>
>> We restart the app server, run the web app, but in the http response,
>> we see that the cache-control response header is not used at all.
>> We use Firebug for diagnostics.
>>
>> Could someone please confirm that this option is indeed supported
>> (tested/verified) on this version of Glassfish. Is there perhaps a
>> known issue regarding this (maybe somehow related to this kind of
>> rails deployment?), or are we simply doing something wrong?
>>
>
> I suspect we have a bug. setCacheControl is a value originally used by
> the WebContainer and not http engine (Grizzly), on which JRuby support
> build on. So the setCacheControl functionality support is missing
> inside the grizzly-jruby extension. Can you file an issue here:
>
> https://glassfish.dev.java.net/servlets/ProjectIssues
>
> Should be simple to fix.
>
> A+
>
> -- Jeanfrancois
>
>
>> Thanks
>> [Message sent by forum member 'mileoresko' (mileoresko)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=324995
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>