ICEfaces
  1. ICEfaces
  2. ICE-5038

Jarred Facelets Templates are continuously refreshed

    Details

    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      set the following in web.xml to turn off Facelets timestamp checking:

      <context-param>
              <param-name>facelets.REFRESH_PERIOD
              </param-name>
              <param-value>-1</param-value>
      </context-param>
      Show
      set the following in web.xml to turn off Facelets timestamp checking: <context-param>         <param-name>facelets.REFRESH_PERIOD         </param-name>         <param-value>-1</param-value> </context-param>

      Description

      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.

        Activity

        Hide
        Mark Collette added a comment -

        Subversion 21507
        repo : 3rd\facelets\src\java\com\sun\facelets\impl\DefaultFaceletFactory.java

        Merged in the change to DefaultFaceletFactory.java corresponding to thier CVS version of 1.14 (from 1.13), as part of Facelets bugs 336, 374.

        Subversion 19489
        icefaces\lib\icefaces-facelets.jar

        I also examined other changes to the file to see if we should merge those in as well, but the only ones of importance were already in our code-base.

        Show
        Mark Collette added a comment - Subversion 21507 repo : 3rd\facelets\src\java\com\sun\facelets\impl\DefaultFaceletFactory.java Merged in the change to DefaultFaceletFactory.java corresponding to thier CVS version of 1.14 (from 1.13), as part of Facelets bugs 336, 374. Subversion 19489 icefaces\lib\icefaces-facelets.jar I also examined other changes to the file to see if we should merge those in as well, but the only ones of importance were already in our code-base.

          People

          • Assignee:
            Unassigned
            Reporter:
            Philip Breau
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: