gwt 2.5/PrecompressLinker useless with tomcat/jboss?

[dhartford]

Hi all,
I've been trying to utilize http://code.google.com/p/google-web-toolkit/wiki/PrecompressLinker, but for (I'm assuming) the common usecase of deploying to Tomcat, or to Jboss, this seems useless/no value.

With tomcat, only configuration I could find was to modify server.xml with Connector ...compression="on" .. configurations which RE-compresses (instead of using pre-compressed) outgoing content, seemingly on the fly for every request. Jboss seems to have similar challenges.

Has anyone had success where using the GWT PrecompressLinker provided value to Tomcat environments (opposed to jetty)?  I know this isn't a direct GWT question, but having a cool feature and being unable to use it leads one wanting... :-)

-Darren

[Jens]

No idea if tomcat/jboss support it or not but in case they don't you can always have a web server in front of your application server. This web server would serve your static pre-compressed GWT client files and proxies remote service calls to your application server. Apache and Nginx can be configured to do so.

-- J.

[Joseph Lust]

I'd like to second Jens' suggestion. I've been pushing all static, precompressed content to AWS CloudFront with the proper gzip headers. Then the app server (Tomcat) only handles RPC's and the root .html page. Using the AWS API's, scripting this deployment behavior has been quite simple to do. 

Hope that helps.

Sincerely,

Joseph

[jhulford]

To handle this in Tomcat, I wrote a little servlet filter that basically uses a request wrapper to re-write the request, pointing it to the precompressed .gz version of the files if the request has a gzip Accept-Encoding header before forwarding it through the filter chain.  Then changed the response's encoding to be gzip and the mime-type to be the original request's mime-type.

Sorry, can't share the code, but it seems to be working fine for us.

[jhulford]

I never encountered this issue. I had a separate filter sitting in front of all the GWT files adding all the appropriate cache headers for any file that didn't have nocache in the name.   Are you sure you're sending the correct response headers to indicate to the browser it can be cached?  

On Thursday, November 22, 2012 9:29:16 AM UTC-6, pop_ionut84 wrote:

Hi
I've used the same scenario for serving .gz precompressed with a servlet filter.
My only problem is that my .gz files doesn't get cached by the browser. Did you found a solution for this?

Regards

[Hua Zhang]

The easiest solution is using tomcat8, see https://tomcat.apache.org/tomcat-8.0-doc/default-servlet.html#change

If a gzipped version of a file exists (a file with .gz appended to the file name located alongside the original file), Tomcat will serve the gzipped file if the user agent supports gzip and this option is enabled. [false] 

[Peter Donald]

You can use GWTGZipFilter from

https://github.com/realityforge/gwt-cache-filter

to achieve the same

> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-tool...@googlegroups.com.
> To post to this group, send email to google-we...@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.



--
Cheers,

Peter Donald