PUBLIC - Liferay Portal Community Edition

setPortletMode and setWindowState aren't working correctly

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 5.1.2
  • Fix Version/s: None
  • Component/s: Framework/API
  • Labels:
    None
  • Environment:
    Tomcat 5.5
  • Branch Version/s:
    5.1.x, 5.2.x
  • Backported to Branch:
    Committed
  • Similar Issues:
    Show 4 results 
  • Liferay Contributor's Agreement:
    Accept

Description

We have some problems with the ActionResponses setPortletMode and setWindowsState methods since we moved to liferay version 5.x (with Tomcat 5.5).
The portal doesn't seem to manage the portlets window state and mode correctly. It looses the portlets window state and mode after they were set by the two methods by restoring it's previous settings.

We are doing the following:

1. process a portlet action and set the portlets window state and portlet mode in the portlets processAction method
2. When the portlet is rendered for the first time directly after the state/mode change, then the portlet seems to be in the correct state and portlet mode. (getPortletMode / getWindowState are equal to the new settings )
3. Afterwards - when the page is rendered again - then the portlet falls back to its previous window state and portlet mode (f.e. when you make a round trip to another tab)

It worked well using the Liferay 4.x versions.

kind regards

Tobias

Attachments

  1. GZip Archive
    liferayTestPortlet.tar.gz
    13/Oct/08 3:20 AM
    777 kB
    Tobias Gindler
  2. Text File
    PortletModePatch.txt
    17/Jun/09 4:10 PM
    3 kB
    Peter Oxenham
  4. Java Source File
    SessionLayoutClone.java
    05/Feb/10 5:28 PM
    3 kB
    Brian Chan

Issue Links

This issue is duplicated by:
LPS-6874 Portlet modes can't be changed Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tobias Gindler added a comment -

I have created a small test project for this issue.
Please take a look at the attached file.

Show
Tobias Gindler added a comment - I have created a small test project for this issue. Please take a look at the attached file.
Hide
Permalink
Peter Oxenham added a comment - - Restricted to

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

Show
Peter Oxenham added a comment - - Restricted to 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
Hide
Permalink
Peter Oxenham added a comment -

SWF screen cast describing the problem

Show
Peter Oxenham added a comment - SWF screen cast describing the problem
Hide
Permalink
Peter Oxenham added a comment - - Restricted to

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

Show
Peter Oxenham added a comment - - Restricted to 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
Hide
Permalink
Peter Oxenham added a comment - - Restricted to

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.

Show
Peter Oxenham added a comment - - Restricted to 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.
Hide
Permalink
Jean-Luc Geering added a comment -

#LEP-4536, #LEP-7534 and #LSP-3471 might be duplicates

Show
Jean-Luc Geering added a comment - #LEP-4536, #LEP-7534 and #LSP-3471 might be duplicates
Hide
Permalink
Erko Hansar added a comment - - Restricted to

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.

Show
Erko Hansar added a comment - - Restricted to 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.
Hide
Permalink
Trever Shick added a comment -

So has anyone been able to work around this issue. It's quite annoying.

Show
Trever Shick added a comment - So has anyone been able to work around this issue. It's quite annoying.
Hide
Permalink
Peter Mesotten added a comment -

This really needs some attention indeed.

Show
Peter Mesotten added a comment - This really needs some attention indeed.
Hide
Permalink
Lou Sacco added a comment -

I've tried the patch as well and it does not seem to address our issue. I also tried Tomcat 6.0.18 on Liferay 5.2.3 EE and still see the issue.

Show
Lou Sacco added a comment - I've tried the patch as well and it does not seem to address our issue. I also tried Tomcat 6.0.18 on Liferay 5.2.3 EE and still see the issue.
Hide
Permalink
Rutvij Shah added a comment - - Restricted to

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

Show
Rutvij Shah added a comment - - Restricted to 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/)
Hide
Permalink
Brian Chan added a comment -

Attached a possible fix which is a modification of the contributed patch. Still needs testing.

Show
Brian Chan added a comment - Attached a possible fix which is a modification of the contributed patch. Still needs testing.
Hide
Permalink
Brian Chan added a comment -

Daenyoung just validated that the fix works. Checked in.

Show
Brian Chan added a comment - Daenyoung just validated that the fix works. Checked in.
Hide
Permalink
Brian Chan added a comment - - Restricted to

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.

Show
Brian Chan added a comment - - Restricted to 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.
Hide
Permalink
Brian Chan added a comment - - Restricted to

I take it back ,the actual fix is in trunk rev 45699. See the diff there via Fisheye.

Thanks Daeyoung.

Show
Brian Chan added a comment - - Restricted to I take it back ,the actual fix is in trunk rev 45699. See the diff there via Fisheye. Thanks Daeyoung.

People

Vote (9)
Watch (8)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.4#664-r167664) | Report a problem
Powered by a free Atlassian JIRA open source license for Liferay. Try JIRA - bug tracking software for your team.