|
I deployed your test program and it proved the issue perfectly.
I have attached a video screen cast describing the problem. I am using v5.2.3 SWF screen cast describing the problem
I believe I know what the problem is, and it seems to have something to do with running Liferay in Tomcat.
When ActionResponse.setPortletMode(EDIT) is called, it eventually calls com.liferay.portal.util.PortalImpl.updatePortletMode() At the bottom of the method it does the following: LayoutClone layoutClone = LayoutCloneFactory.getInstance(); if (layoutClone != null) { layoutClone.update( request, layout.getPlid(), layout.getTypeSettings()); } which by default calls SessionLayoutClone.update(). This in turn saves the "type settings" in the requests HttpSession. The problem is that the HttpSession returned from the request is not the same HttpSession used by ServicePreAction.servicePre() when it retrieves the typeSettings out of the request. Then retrieving the "type settings", the request is in the ROOT (i.e. liferay's) servlet context, but saving the "type settings" is performed in the portlets servlet context which in this case is NOT the ROOT context. When dispatching a request "cross context" Tomcat uses the session manager for the current context. Therefore the two HttpSession's returned by Tomcat are different. The piece of Tomcat code in particular is org.apache.catalina.core.ApplicationHttpRequest.getSession(boolean) and crossContext is equal to true Have found a fix for this problem. I've attached a patch file.
The fix was to use the shared HttpSession from SharedSessionServletRequest in the SessionLayoutClone class. The shared session is the same one used to get the type settings in service pre action. We have this exact problem (liferay 5.2.3, tomcat 6.0.18) with our custom portlets:
1) switch to edit mode 2) press some save button to submit an action in edit mode (the request URL contains maximized state and edit mode parameters) 3) portlet code stores the changes and sets VIEW mode and NORMAL state in the action response 4) portlet switches back into view mode and normal size on the first display (the request URL contains maximized state and edit mode parameters but the effective values were changed in portlet action method) 5) but the next request can drop it back into EDIT mode and maximized view I tried out the contributed solution (by Peter) and it solved the problem partially for me. With this solution, any random request in step 5 will work correctly now, but some (for example the link behind "Configuration" option in portlet header) requests will still have the wrong EDIT state marked for this portlet. So the user goes through 1-2-3-4 and then clicks Configuration link in portlet header options. Portlet configurations page is displayed and a "Return to Full Page" link is displayed. When user clicks Return to Full Page, he will be show the portlet in EDIT mode and maximized state (not VIEW mode and normal state, as expected). It's happening because the Configuration option drags along _86_redirect and _86_returnToFullPageURL parameters which, for some reason, are very similar to the URL constructed in step 2 - they still contain maximized state and edit mode parameters. So has anyone been able to work around this issue. It's quite annoying.
This really needs some attention indeed.
I found one workaround which will work without changing liferay source code.
Need to add few Query String parameters to Portal Page which contains the portlet. p_p_id=<PortletId>&p_p_lifecycle=0&p_p_state=normal&p_p_mode=view <PortletId> : It is the portlet Id for target Portlet I have tested it on Tomcat 5.5, Tomcat 6.0, Websphere 6.1 with Liferay 5.2.3. Its working fine. for detailed steps have a look on my blog (http://rutvijshah.wordpress.com/2010/01/10/work-around-making-setportletmode-working-in-liferay/) Attached a possible fix which is a modification of the contributed patch. Still needs testing.
Daenyoung just validated that the fix works. Checked in.
Actually, the code change is not needed at all.
Simply change this in portal.properties session.shared.attributes=org.apache.struts.action.LOCALE,COMPANY_,USER_,LIFERAY_SHARED_ by setting portal-ext.properties session.shared.attributes=org.apache.struts.action.LOCALE,com.liferay.portal.util.SessionLayoutClone,COMPANY_,USER_,LIFERAY_SHARED_ We're testing out this simpler fix now. I take it back ,the actual fix is in trunk rev 45699. See the diff there via Fisheye.
Thanks Daeyoung. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Minor
setPortletMode and setWindowState aren't working correctly
Please take a look at the attached file.