ICEfaces
  1. ICEfaces
  2. ICE-11356

Myfaces specific - Diff propagated to root but no ID set [html: null] server error

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.3.0.GA_P05
    • Fix Version/s: EE-3.3.0.GA_P05
    • Component/s: Sample Apps
    • Labels:
      None
    • Environment:
      ICEfaces EE-3.3.0 maintenance branch r51830, Tomcat 7, all browsers, myfaces 2.1.17. Not an issue with P04 libs.
    • Assignee Priority:
      P1
    • Workaround Exists:
      Yes
    • Workaround Description:
      Set an ID to the <h:head> tag.

      Description

      Occasionally when deploying a myfaces app to the server and when interacting with certain samples, the following error was seen:
      16-Aug-2017 14:15:18.674 SEVERE [http-apr-8080-exec-9] org.icefaces.impl.util.DOMUtils.nodeDiff Diff propagated to root but no ID set [html: null]

      In the case of fajax, scopes and elementUpdate apps, several tests fail because the first click of a button is not registered with a count increment and causes the above error. The next click is registered and incremented properly. This causes a counter to go from 0 to 2.

      To reproduce:
      Build the Scopes app with Dmyfaces=true.
      Open the application scope test.
      Click the '+' button once. The counter remains at 0 and the error can be seen in the server log.
      Click the '+' button again. The counter is increased to 2.

        Activity

        Hide
        Ken Fyten added a comment -

        Historically this type of issue has been caused by a lack of IDs on DOM elements to enable dom-diffing at lower than the root level.

        Show
        Ken Fyten added a comment - Historically this type of issue has been caused by a lack of IDs on DOM elements to enable dom-diffing at lower than the root level.
        Hide
        Ken Fyten added a comment -

        Also note when running with Myfaces the following recommended config settings, which should be automatically added if you build using our -MyFaces flag:

         <context-param>
                <param-name>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</param-name>
                <param-value>false</param-value>
            </context-param> 
        
        Show
        Ken Fyten added a comment - Also note when running with Myfaces the following recommended config settings, which should be automatically added if you build using our -MyFaces flag: <context-param> <param-name>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</param-name> <param-value> false </param-value> </context-param>
        Hide
        Arturo Zambrano added a comment -

        The workaround is to set an ID to the <h:head> tag. If there's no ID specified in <h:head>, MyFaces will assign it the ID '__3', in this case, the very first time the page is loaded. After the first request, the ID of the head will be changed to 'javax.faces.ViewHead'. Because of this, the diff propagates to the root <html> node and finds no ID and throws the error. In all subsequent requests, the ID of <h:head> stays as 'javax.faces.ViewHead', so everything works normally from that point on. With Mojarra, the ID of <h:head> is 'javax.faces.ViewHead' from the beginning. So, this issue is not present there.

        I also tried implementing the redirection navigation approach used in the showcase app to avoid the jessionid parameter on the first request, but this didn't solve the issue.

        It seems like ICE-10120 fixed this same issue in the 4.0 trunk. I'm going to backport it to the 3.3 EE maintenance branch and see if that fixes the issue.

        Show
        Arturo Zambrano added a comment - The workaround is to set an ID to the <h:head> tag. If there's no ID specified in <h:head>, MyFaces will assign it the ID '__3', in this case, the very first time the page is loaded. After the first request, the ID of the head will be changed to 'javax.faces.ViewHead'. Because of this, the diff propagates to the root <html> node and finds no ID and throws the error. In all subsequent requests, the ID of <h:head> stays as 'javax.faces.ViewHead', so everything works normally from that point on. With Mojarra, the ID of <h:head> is 'javax.faces.ViewHead' from the beginning. So, this issue is not present there. I also tried implementing the redirection navigation approach used in the showcase app to avoid the jessionid parameter on the first request, but this didn't solve the issue. It seems like ICE-10120 fixed this same issue in the 4.0 trunk. I'm going to backport it to the 3.3 EE maintenance branch and see if that fixes the issue.
        Hide
        Arturo Zambrano added a comment -

        r51848: exempt the head component from having its ID shortened

        Show
        Arturo Zambrano added a comment - r51848: exempt the head component from having its ID shortened
        Hide
        Liana Munroe added a comment - - edited

        Tested with ICEfaces EE -3.3.0 maintenance branch r51849. The fajax and scopes application issues are resolved and the server error is no longer seen.
        The elementUpdate application has an issue where the initial press of any button does not immediately update the page. During the second or subsequent submits the page is updated properly. Not an issue with P04 libs. Not an issue with mojarra. No server errors are seen.

        Show
        Liana Munroe added a comment - - edited Tested with ICEfaces EE -3.3.0 maintenance branch r51849. The fajax and scopes application issues are resolved and the server error is no longer seen. The elementUpdate application has an issue where the initial press of any button does not immediately update the page. During the second or subsequent submits the page is updated properly. Not an issue with P04 libs. Not an issue with mojarra. No server errors are seen.
        Hide
        Arturo Zambrano added a comment - - edited

        The last issue is not caused by the fix committed for this JIRA. It started at revision 51435, with the fix for ICE-11288. It's a simple, atomic fix that solves ICE-11288. If we revert it, it would break ICE-11288. Perhaps the only solution would be to avoid applying that fix in MyFaces environments, assuming that this won't break ICE-11288 on MyFaces.

        Show
        Arturo Zambrano added a comment - - edited The last issue is not caused by the fix committed for this JIRA. It started at revision 51435, with the fix for ICE-11288 . It's a simple, atomic fix that solves ICE-11288 . If we revert it, it would break ICE-11288 . Perhaps the only solution would be to avoid applying that fix in MyFaces environments, assuming that this won't break ICE-11288 on MyFaces.
        Hide
        Arturo Zambrano added a comment -

        r51854: modified EnvUtils.isICEfacesView method to avoid applying the ICE-11288 fix to MyFaces environments

        Show
        Arturo Zambrano added a comment - r51854: modified EnvUtils.isICEfacesView method to avoid applying the ICE-11288 fix to MyFaces environments
        Hide
        Liana Munroe added a comment -

        Verified scopes and elementUpdate apps, ICEfaces EE-3.3.0_P05 Jenkins build 1, Tomcat 8, myfaces and mojarra libs.

        Show
        Liana Munroe added a comment - Verified scopes and elementUpdate apps, ICEfaces EE-3.3.0_P05 Jenkins build 1, Tomcat 8, myfaces and mojarra libs.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Liana Munroe
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: