The current strategy for compressing resources in ICEfaces is somewhat inconsistent with what we've done in the past. In ICEfaces 1.x, we typically compressed nearly all of the resources we served ourselves, with the behaviour being modified though the use of a context parameter:

    <context-param>
        <param-name>com.icesoft.faces.compressResources</param-name>
        <param-value>false</param-value>
    </context-param>

 With ICEfaces 2.x and above, the context parameter remains (although changed to reflect the packaging changes in the product):

    <context-param>
        <param-name>org.icefaces.compressResources</param-name>
        <param-value>false</param-value>
    </context-param>

but the behaviour only applies to a subset of the resource served. This includes the compat resources served via CompatResourceServlet as well as any resources added to the ResourceRegistry via methods like addSessionResource(Resource resource). This is typically done in certain components (File Entry, Data Exporter) and can also be used by application code.

There are a couple of different issues with this approach. One is that it's inconsistent. Some resources are compressed and some (like jsf.js or bridge.js) are not compressed by ICEfaces at all. Another is that, since it's on by default and only some resources are compressed, it's possible that certain resources could be compressed external to ICEfaces. Liferay is an example where it compresses many text files by default. Since the compression isn't centralized, this can lead to double-compression. Something that's not handled well by most browsers (Chrome being the exception).

After some internal discussion, we decided that the best thing to do is:

- turn off our compression by default, leaving the context parameter available to re-enable compression if desired
- document other means of enabling compression in a more central, standardized way


JSF

One way such way is to configure JSF to do the compression. With Mojarra, this can be done with a context parameter where the desired content-types are specified:

    <context-param>
        <param-name>com.sun.faces.compressableMimeTypes</param-name>
        <param-value>text/css</param-value>
    </context-param>

The list of types is comma separated and supports the wildcard character ('*'):
http://javaserverfaces.java.net/nonav/rlnotes/2.0.0/whatsnew.html
http://docs.jboss.org/jbossas/6/JSF_Guide/en-US/html/jsf.reference.html#mojarra.config.params

With the MyFaces implementation, it's a bit more involved. You need to add a MyFaces Commons library and then set one or more context parameters:
http://myfaces.apache.org/commons20/myfaces-resourcehandler20/index.html

Note: In both implementations, if the project stage is set to Development, then no compression will occur. However, this only applies to JSF's compression, not compression accomplished through other means.

    <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Development</param-value>
    </context-param>


Platform Specific

The other, recommended option is to let your container or web server (e.g. Apache) handle the compression. Nearly every server has some sort of mechanism to provide and configure compressions on the responses:


Tomcat 7
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

Compression is off by default but you can set one or more attributes of the HttpConnector (compression, compressableMimeType, compressionMinSize) to control what type and size of file gets compressed.