Due to an apparent bug in Facelets 1.1.14 (fixed in Facelets 1.1.15b1) any facelet template or composition component contained within a jar is continuously refreshed, whether the file has been updated or not. This occurs when the facelets.REFRESH_PERIOD context parameter is set to a value greater than -1. Having the Facelets continuously refreshes may cause aberrant behaviour in ICEfaces applications, such as constant redirection if the refreshed Facelets are contained in the head element, and DOM diffs that are much larger than expected due to changing component ids (which occurs with auto-generated ids when a Facelet is refreshed).

This bug occurs because the Facelets 1.1.14 uses the following logic when deciding to refresh the file (DefaultFaceletFactory.needsToBeRefreshed(DefaultFacelet)):
            
long ttl = facelet.getCreateTime() + this.refreshPeriod;
...
URLConnection conn = url.openConnection();
is = conn.getInputStream();
long atl = conn.getLastModified();
return atl == 0 || atl > ttl;

The problem is that the org.jboss.net.protocol.file.FileURLConnection.getLastModified() method returns 0 for jarred resources, as does the implementation for other app servers, such as Glassfish 2.1, so the above method always returns true for jarred resources.

A patch was accepted into the Facelets head to correct this:

https://facelets.dev.java.net/issues/show_bug.cgi?id=336

long ttl = facelet.getCreateTime() + this.refreshPeriod;
...
URLConnection conn = url.openConnection();
is = conn.getInputStream();
long atl = conn.getLastModified();
return atl > ttl;

We should incorporate this change into icefaces-facelet jar to avoid the issue.