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. On Friday, October 26, 2012 6:23:15 PM UTC-4, dhartford wrote: > > 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 > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/L5Ddh_4pj7IJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
