ICEfaces
  1. ICEfaces
  2. ICE-3424

ICEfaces 1.7.1 not compatible with JSF version 1.2_09

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.7.1
    • Fix Version/s: 1.7.2
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces 1.7.1 and JSF 1.2_09

      Description

      An incompatibility between ICEfaces and JSF 1.2_09 exists. Users are reporting blank pages showing up in rendering phases.

        Issue Links

          Activity

          Hide
          Greg Dick added a comment -

          In the JSF RestoreViewPhase implementation there are a couple of paths of execution. If the UIViewRoot is stored in the FacesContext implementation, that object is used and restoreView/createView are never called. If the request is deemed to be a postback, this UIViewRoot is used for the rest of the lifecycle.

          If the request is not deemed to be a postback, the responseComplete flag is set in the facesContext. This will prevent any further processing being done on the lifecycle, including rendering. This is the nature of the problem. We have knowledge of what type of request is incoming and this allows us to clear the viewRoot instance from the FacesContext. Our use of the perisistent FacesContext is the root of the difficulty. We preserve some of its state if a non-faces request is used in a redirect, but we don't if the non-faces request is part of a page reload.

          I've made some changes to the View and to the BridgeFacesContext, and am in the process of checking for regressions.

          Show
          Greg Dick added a comment - In the JSF RestoreViewPhase implementation there are a couple of paths of execution. If the UIViewRoot is stored in the FacesContext implementation, that object is used and restoreView/createView are never called. If the request is deemed to be a postback, this UIViewRoot is used for the rest of the lifecycle. If the request is not deemed to be a postback, the responseComplete flag is set in the facesContext. This will prevent any further processing being done on the lifecycle, including rendering. This is the nature of the problem. We have knowledge of what type of request is incoming and this allows us to clear the viewRoot instance from the FacesContext. Our use of the perisistent FacesContext is the root of the difficulty. We preserve some of its state if a non-faces request is used in a redirect, but we don't if the non-faces request is part of a page reload. I've made some changes to the View and to the BridgeFacesContext, and am in the process of checking for regressions.

            People

            • Assignee:
              Unassigned
              Reporter:
              Greg Dick
            • Votes:
              8 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: