Solution for the problem.

Please ignore the first patch.
This actually works, though it is just a workaround, I still do not know why the event listener is called twice.
I guess it is caused by revisiting the DOM for the changes, but I am not sure.
Maybe you can bring light into this.

The patch submitted before did not work in all cases, here is a solution which fits in better.

If multiple copies of icefaces.jar are present in the web application, these event listeners will be called twice. Is this the case?

How did you detect that components are duplicated and what negative effect does this have on the application?

It is not the case.I have reviewed the issue into a certain depth and found the listener to be invoked in both, RestoreViewPhase and RenderPhase.
This only happens when PartialViewContext.isRenderAll is true.
It also could point to a problem with the bridge. Please also note the issue ICE-6644 I have created. Thank you.

Are you able to observe this in any of the sample application provided with ICEfaces 2? If so, include steps to reproduce and observe the problem. The other JIRA mentions a portlet use case. Do you observe this problem with both portlets and servlets?

Modified patch to remove whitespace diff so it's easier to evaluate the impact of the relevant changes.

Mircea, please evaluate the impact of the ICE-6433-2 patch on the current ICEfaces 2 trunk code. The patch has been submitted by a customer in related to doing Ajax navigation in a portal.

Christian, can you please provide a simple test case that we can use to verify the problem and the fix and that we could potentially add to our regression test suite.

I used a test application that has both redirecting and forwarding navigation rules. In both cases the system event handler is invoked only once, right after a new HtmlForm component is added to the component tree.

Of course during navigation the JSF lifecycle is ran twice, each time with a newly created component tree. The first lifecycle is triggered by the postback that initiated the navigation. The second lifecycle corresponds to the view defined by the navigation case.

Until I see a test case that contradicts these finding I'm marking this issue as "Cannot Reproduce".

Need to test in Liferay.

Sorry it took me so long, I had to simplify my portlet-application.
I did not include my ant-build file since it is very special, but you should be able to compile the srcs and then do a war (with WebContent to the root and the compiled classes to "WEB-INF/classes").

I hope you can reproduce the problem now.

Christian

It turns out that, under certain situations related to dynamic includes and composite components, the PostAddToViewEvent can be called multiple times (RESTORE_VIEW, RENDER_RESPONSE) during the same JSF lifecycle. Since we only care about adding the components from WindowAndViewIDSetup and FormSubmit during the render phase, I've added a check for the current phase and bail out if it's not the render phase.

With this fix and the related navigation fixes in the latest version of the bridge, the supplied test case now works as originally designed. Resolving as fixed.

Re-opening the case for further investigation.

It might be worthwhile to test a non-portlet app with composite components and non-redirect navigation.

I had added in this guard to ensure it only ran in one phase:

if( context.getCurrentPhaseId() != PhaseId.RENDER_RESPONSE )

Which worked splendidly to fix the supplied test case. Further testing in other behaviours was not so joyous. It turns out that the PostAddToViewEvent is sometimes fired:

• only during RENDER_RESPONSE
• only during RESTORE_VIEW
• during both phases

So I reverted the fix back out again and will continue to investigate.

The previous failure appears to have been related to a different issue (the minification problems of the Compat related JavaScript libs). It would work to load the portlet and allow one click to succeed and add a new panel but further button actions did not work.

I reverted everything to the latest trunks (icefaces and portletfaces), rebuilt everything, and retested with the phase-checking reinstated back into WindowAndViewIDSetup and FormSubmit classes. Both test cases worked (the portlet navigation and the 'required' validation).

This commit is causing new regression failures with:

http://10.18.39.129:8080/ICE-4090 (drop down list not working the first time)
http://10.18.39.129:8080/ICE-3618 (reset button not working)
http://10.18.39.129:8080/ICE-4158 (drop down list not working the first time)

Ted's analysis:

The following is missing on the first page load causing a
full <form> update:

<script id="iceForm:iceForm_captureSubmit" type="text/javascript">ice.captureSubmit('iceForm',false);ice.captureEnterKey('iceForm');</script>

Confirmed ICE-4090 is resolved when the SystemEventListener s are reverted.

The earlier analysis was slightly reversed: the ice.captureSubmit() JavaScript is actually missing from Ajax update not the initial page render.

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.

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

The most recent fix uses the following technique:

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

+ 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).

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.)

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.