The gzip filter should be before Wicket filter. This way it has the chance
to manipulate the response generated by Wicket.
Wicket just calls httpServletResponse.setContentType("text/application")
and httpServletResponse.write(someStringWithJS).
GZipFilter's job is to change the content type and gzip the JS string.
I recommend you to put a breakpoint in GZipFilter and see what happens.

On Thu, Nov 29, 2012 at 8:30 PM, Nick Pratt <nbpr...@gmail.com> wrote:

> Ive enabled Gzip compression via the Jetty filter for my application (Jetty
> v6 and v8).
> Based on Chrome Dev Tools and Firebug in Firefox, my .js and .css files are
> not being compressed (browser states in the request that it will take gzip
> response), although text/html is, and Im trying to understand why.
> Ive got the mimeTypes configured in the GzipFilter servlet, minGzipSize
> defaults to 0 bytes.
> In Wicket 6, is there anything going on with the resources that would
> prevent Jetty's GzipFilter from working?
> Ive tried placing the filter both before and after the WicketFilter.
> Chrome's PageSpeed analyzer also thinks most of my larger JS files are not
> compressed (Ive been looking at the Response headers)
> Any thoughts?
> N

Martin Grigorov
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>

Reply via email to