ICEfaces
  1. ICEfaces
  2. ICE-6643

WindowAndViewIDSetup and FormSubmit: Event handlers cause duplicate components

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 2.0.0
          • Fix Version/s: 2.0.1
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            JBoss 5.1
            JSF 2.1
            Portlet-Faces-Bridge 2.0.0 BETA4
          • Affects:
            Sample App./Tutorial
          • Workaround Exists:
            Yes
          • Workaround Description:
            Hide
            Please add a

            if (event instanceof PostAddToViewEvent) {
            <original source>
            }

            to the "processEvent(SystemEvent event)"- Method.
            Show
            Please add a if (event instanceof PostAddToViewEvent) { <original source> } to the "processEvent(SystemEvent event)"- Method.
          • Community Contribution:
            Yes

            Description

            While executing an AJAX-Request with a full render (by navigation-case), the components in the event handlers are to be added a second time.
            This results from the Listener to handle the event twice.
            2. Text File
              ICE-6643-2.patch
              3 kB
              Deryk Sinotte
            3. Text File
              Patch - Icefaces_Events.patch
              14 kB
              Christian Heike
            4. Text File
              Patch - Icefaces_Events.patch
              13 kB
              Christian Heike

              Activity

              Ascending order - Click to sort in descending order
              16 older comments
              Hide
              Permalink
              Ted Goddard added a comment -

              Porting the sample to a Servlet test case shows the following in the log when clicking on "Greetings":

              SEVERE: JSF1007: Duplicate component ID j_idt7:menuForm:menuForm_windowviewid found in view.

              Show
              Ted Goddard added a comment - Porting the sample to a Servlet test case shows the following in the log when clicking on "Greetings": SEVERE: JSF1007: Duplicate component ID j_idt7:menuForm:menuForm_windowviewid found in view.
              Hide
              Permalink
              Ted Goddard added a comment -

              Attached test.zip contains files to be added to component-showcase to reproduce both ICE-4090 and this issue in a Servlet application.

              Show
              Ted Goddard added a comment - Attached test.zip contains files to be added to component-showcase to reproduce both ICE-4090 and this issue in a Servlet application.
              Hide
              Permalink
              Ted Goddard added a comment -

              The most recent fix uses the following technique:

              + //guard against duplicates within the same JSF lifecycle
              + if (null != context.getAttributes().get(componentId))

              { + return; + }

              + context.getAttributes().put(componentId, componentId);
              +

              It was observed that the duplicate components were added during the same lifecycle, so the above check ensures that the component is added only once per FacesContext instance. It is possible that this technique makes some of the other duplicate-checking obsolete, however, this may not be the case since other cases of duplication result from differences in event handling after state saving (this is why the use of component attribute markers is dangerous since the markers may be state-saved with the component even though the transient component is not saved).

              Show
              Ted Goddard added a comment - The most recent fix uses the following technique: + //guard against duplicates within the same JSF lifecycle + if (null != context.getAttributes().get(componentId)) { + return; + } + context.getAttributes().put(componentId, componentId); + It was observed that the duplicate components were added during the same lifecycle, so the above check ensures that the component is added only once per FacesContext instance. It is possible that this technique makes some of the other duplicate-checking obsolete, however, this may not be the case since other cases of duplication result from differences in event handling after state saving (this is why the use of component attribute markers is dangerous since the markers may be state-saved with the component even though the transient component is not saved).
              Hide
              Permalink
              Ted Goddard added a comment -

              Please test the latest trunk in the portal environment that previously reproduced the problem. (It has also been reproduced with a Servlet, but the fix needs verification in a Portlet environment.)

              Show
              Ted Goddard added a comment - Please test the latest trunk in the portal environment that previously reproduced the problem. (It has also been reproduced with a Servlet, but the fix needs verification in a Portlet environment.)
              Hide
              Permalink
              Deryk Sinotte added a comment -

              So there were changes to the following areas that ended up requiring some effort to ensure everything was stable:

              • ICEfaces core
              • ICEfaces components
              • JSF libs
              • PortletFaces bridge

              I updated to the latest code in all the affected areas and modified the examples based on these new libraries. After stabilizing things and re-testing, I think we're back to a point where the attached test case as well as the modified component showcase are both behaving as desired so I'm marking as fixed.

              Neil was kind enough to make a change that should benefit developers looking to utilise init parameters in both the portlet.xml and web.xml files.

              Show
              Deryk Sinotte added a comment - So there were changes to the following areas that ended up requiring some effort to ensure everything was stable: ICEfaces core ICEfaces components JSF libs PortletFaces bridge I updated to the latest code in all the affected areas and modified the examples based on these new libraries. After stabilizing things and re-testing, I think we're back to a point where the attached test case as well as the modified component showcase are both behaving as desired so I'm marking as fixed. Neil was kind enough to make a change that should benefit developers looking to utilise init parameters in both the portlet.xml and web.xml files.

                People

                • Assignee:
                  Deryk Sinotte
                  Reporter:
                  Christian Heike
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: