ICEfaces
  1. ICEfaces
  2. ICE-7080

Issue with UISeries in a rendered=false form during state saving

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: EE-2.0.0.GA, 2.0.2
          • Fix Version/s: 2.1-Beta, 3.0, EE-2.0.0.GA_P01
          • Component/s: ICE-Components
          • Labels:
            None
          • Environment:
            UISeries/PanelSeries
          • Assignee Priority:
            P1

            Description

            A NullPointerException is thrown when displaying a page with the following code:

                    <ice:form id="loginForm" rendered="false">
                        <ice:panelSeries
                            value="#{personBean.searchFacetValueLists}" var="sfvl"
                            rendered="#{login.numConceptsTest != 0}"
                            style="margin-left: 37px;">
                            <ice:outputText value="checking render"
                                            styleClass="refineSearchFacetTitle"
                                            style="margin-top: 10px;" />
                            <br />
                        </ice:panelSeries>
                        <ice:outputText value="#{personBean.tester}"></ice:outputText>
                    </ice:form>

            The NPE is coming from the following code: #{login.numConceptsTest != 0}. The exception is only thrown when using a UISeries component type. It is not evaluated with a basic outputText component.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Arran Mccullough added a comment -

              The exception is happening during state saving. All the rendered attributes are irrelevant for this tree recursion because the whole component tree needs to be saved. When state saving hits the PanelSeries, it has some logic to reset the rowIndex to -1, which should be ok, but that code eventually hits some work-around code we put in for ICE-4066 that looks like some kind of hack to solve another problem. In fact it's likely that if we remove the work-around and test for the regression it'll be ok now because of other code changes since then. Anyways that work-around has a side-effect of testing the rendered property on its parents, which causes the exception.

              Show
              Arran Mccullough added a comment - The exception is happening during state saving. All the rendered attributes are irrelevant for this tree recursion because the whole component tree needs to be saved. When state saving hits the PanelSeries, it has some logic to reset the rowIndex to -1, which should be ok, but that code eventually hits some work-around code we put in for ICE-4066 that looks like some kind of hack to solve another problem. In fact it's likely that if we remove the work-around and test for the regression it'll be ok now because of other code changes since then. Anyways that work-around has a side-effect of testing the rendered property on its parents, which causes the exception.
              Hide
              Permalink
              Arran Mccullough added a comment -

              Should combine the issue reported in ICE-4066 with any fixes for this issue to have one complete solution.

              Show
              Arran Mccullough added a comment - Should combine the issue reported in ICE-4066 with any fixes for this issue to have one complete solution.
              Hide
              Permalink
              yip.ng added a comment -

              This is actually not caused by the rendered attribute, but by the value attribute. There is an exception in the value getter method, triggered by reference to loginBean.getNumConcepts(), which in turn triggers a chain of exception handling code that ultimately loops back to a test for the rendered attribute, which triggers another exception. All very twisted.

              Show
              yip.ng added a comment - This is actually not caused by the rendered attribute, but by the value attribute. There is an exception in the value getter method, triggered by reference to loginBean.getNumConcepts(), which in turn triggers a chain of exception handling code that ultimately loops back to a test for the rendered attribute, which triggers another exception. All very twisted.
              Hide
              Permalink
              yip.ng added a comment -

              Found the simplest fix involving the way CustomComponentUtils.isAncestorRendered() is used. It is used by UISeries only and so should have no side effects. (It was also once used by PanelTabSet but later that change was backed out. Probably it caused the same issues back then.)

              Now if ancestor is not rendered, then neither value nor rendered attribute should give exceptions.

              Revision: 25201

              Modified : /icefaces2/trunk/icefaces/compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java

              Revision: 25202

              Modified : /icefaces2/branches/icefaces-2.0.x-maintenance/icefaces/compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java

              Show
              yip.ng added a comment - Found the simplest fix involving the way CustomComponentUtils.isAncestorRendered() is used. It is used by UISeries only and so should have no side effects. (It was also once used by PanelTabSet but later that change was backed out. Probably it caused the same issues back then.) Now if ancestor is not rendered, then neither value nor rendered attribute should give exceptions. Revision: 25201 Modified : /icefaces2/trunk/icefaces/compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java Revision: 25202 Modified : /icefaces2/branches/icefaces-2.0.x-maintenance/icefaces/compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java

                People

                • Assignee:
                  yip.ng
                  Reporter:
                  Arran Mccullough
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: