Problem with Liferay, ICEfaces, and "immediate" attribute

[Kevin Dean, modifié il y a 10 années.]

I'm trying to track down a problem I'm having with an application. We're seeing some strange behaviour when the "immediate" attribute is set to true on a button.

Normally, we set the "immediate" attribute on any buttons that cancel the current operation. For obvious reasons, we need to bypass the validation process when any such button is pressed. The flow is basically this:

Porlet X -> Initial view A -> User selects option -> Selected view B -> User presses "Cancel" -> Returned to view A

If the "immediate" attribute on the "Cancel" button in view B is left out (or set to false), this is what shows up in the Chrome network monitor (assuming I fill in data that satisfies the validation requirements):

http://localhost:8080/home?p_p_id=session_manager_WAR_Gateway&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=1&_session_manager_WAR_Gateway__jsfBridgeAjax=true&_session_manager_WAR_Gateway__facesViewIdResource=%2Fsession%2Flogin.xhtml

If the "immediate" attribute is set to "true", this is what shows up:

http://localhost:8080/home?p_p_id=session_manager_WAR_Gateway&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=1&_session_manager_WAR_Gateway__jsfBridgeAjax=true&_session_manager_WAR_Gateway__facesViewIdResource=%2Fsession%2Flogin.xhtml
http://localhost:8080/home?p_p_id=session_manager_WAR_Gateway&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=1&_session_manager_WAR_Gateway_javax.faces.resource=jsf.js&_session_manager_WAR_Gateway_ln=javax.faces
http://localhost:8080/home?p_p_id=session_manager_WAR_Gateway&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=1&_session_manager_WAR_Gateway_javax.faces.resource=bridge.js&_session_manager_WAR_Gateway_ln=ice.core
http://localhost:8080/home?p_p_id=session_manager_WAR_Gateway&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=1&_session_manager_WAR_Gateway_javax.faces.resource=util%2Face-jquery.js&_session_manager_WAR_Gateway_ln=icefaces.ace
http://localhost:8080/home?p_p_id=session_manager_WAR_Gateway&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=1&_session_manager_WAR_Gateway_javax.faces.resource=compat.js&_session_manager_WAR_Gateway_ln=ice.compat
http://localhost:8080/home?p_p_id=session_manager_WAR_Gateway&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=1&_session_manager_WAR_Gateway_javax.faces.resource=util%2Face-components.js&_session_manager_WAR_Gateway_ln=icefaces.ace
http://localhost:8080/home?p_p_id=session_manager_WAR_Gateway&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=1&_session_manager_WAR_Gateway_javax.faces.resource=icefaces-compat.js&_session_manager_WAR_Gateway_ln=ice.compat
http://localhost:8080/home?p_p_id=session_manager_WAR_Gateway&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=1&_session_manager_WAR_Gateway_javax.faces.resource=util%2Face-menu.js&_session_manager_WAR_Gateway_ln=icefaces.ace

Note that "localhost" is mapped to an organization site in Liferay.

The first line in the "immediate" true case is the same as the line in the false case. The subsequent lines have several problems.

Problem 1: There's no logical reason for all this extra traffic. Pressing the button in the false case sends only a single request/response; pressing the button in the true case isn't doing anything more from an application perspective so the extra traffic is completely unwarranted.

Problem 2: The first line is properly encoded. The second line has the query parameters escaped, with '&" replaced with "&"; this thoroughly messes things up for Liferay.

Problem 3: As a result of problem 2, bean management goes to hell in a handbasket. All of our beans use @CustomScoped("#{window}") and tracking the constructor for the bean in view A shows that it's being called multiple times, once for each request other than the first one. Deep inspection of the bean map in the window scope shows that a different window map is being created for each request (hardly surprising given the mess of the URLs). This, naturally, has an impact on application functionality as well as on its performance (the constructors often have side effects such as loading data from the database).

Although we're using ICEfaces for the bulk of our components, the problem occurs whether we use <ace:pushButton> or <h:commandButton> to cancel view B; it's the "immediate" attribute that is causing the grief.

At this point, I have no clue as to where the problem lies. I'm cross-posting this problem to the ICEfaces forums in case it has anything to do with their window scope, Javascript files, or components.

The attached file contains HTTP archives of all the traffic.

[Kevin Dean, modifié il y a 10 années.]

The ICEfaces post is here:

http://www.icesoft.org/JForum/posts/list/0/21938.page#77165

[Neil Griffin, modifié il y a 10 années.]

My best guess is that submission of the button with ace:pushButton is causing an ICEfaces DOM-diff on the server, which is causing some <script src="..." /> elements to come back in the partial-response. The DOM-diff might be valid, or it might be invalid (in some sense). Sometimes it is possible to prevent an ICEfaces DOM-diff by surrounding offending elements with an h:panelGroup component.

When you click on the button, there should be an HTTP POST request sent via Ajax. I would recomment that you examine the partial-response that comes back from theserver and see what's being replaced in the DOM.

[Kevin Dean, modifié il y a 10 années.]

The problem isn't restricted to <ace:pushButton>; it occurs with <h:commandButton> as well.

The difference between the two DOMs is substantial. The first HAR file in the ZIP I posted is 19kB in size, the second is 268kB. When I compare only the outgoing requests to the server, they are identical, something I find quite mystifying given the difference in response.

Surrounding the offending element with <h:panelGroup> makes no difference.

[Neil Griffin, modifié il y a 10 années.]

When you get a chance, please post a stripped-down (really minimal) xhtml view here that reproduces the problem.

[Kevin Dean, modifié il y a 10 années.]

I'll see if I can get one done today.

[Kevin Dean, modifié il y a 10 années.]

Here you go. The Immediate_Bug.war file is the final deployed WAR file after Liferay does its thing; the Immediate_Bug_src.zip file is the source.

The test is very simple:

• Install the portlet.
• Start network activity monitor.
• Press the button.
• Note only one request/response pair in activity monitor.
• Press the button.
• Note multiple request/response pairs in activity monitor.
• Press the button.
• Note multiple request/response pairs in activity monitor. It seems that the "immediate" setting corrupts further interaction with the portlet.

This is deployed to GlassFish 3.1.2.2.