ICEfaces
  1. ICEfaces
  2. ICE-5862

Multiple windows/tabs open to the same portal page incorrectly dispose of all associated views

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.2-EE-GA_P01, 1.8.2a
    • Fix Version/s: 1.8.3, 1.8.2-EE-GA_P02
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces 1.8 Portals Portlets
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.)

      Description

      We have logic that, as views for a portal page are created, associates those views together in a collection. This collection can then be used during view disposal so that if one view is disposed, they can all be disposed. The reason this is necessary is that the dispose-views requests are initiated by the client. But in cases where the client does not know about all the views in a portal page (e.g. navigating away before all the portlets on the page completely render, or an exception in one or more portlets), it's possible to have Views created on the server that do not get diposed of until the session expires. By associating all the views on a page together, if one is disposed, they can all be disposed.

      However, determining the key value for associating portlet views together relies on proprietary code in the portal container. Typically this will be something like a page name. The problem occurs if the page name is not uniquely instanced in some way. In this case, if more than one tab or window is open to the same page, all views on all the tabs/windows will be bound under the same key. When one is disposed, all views in all tabs/windows are disposed which leads to exceptions when trying to interact with the other, still active tabs.

        Activity

        Hide
        Deryk Sinotte added a comment -

        Linking to SalesForce case.

        Show
        Deryk Sinotte added a comment - Linking to SalesForce case.
        Hide
        Ted Goddard added a comment -

        It may be possible to use reflection to obtain the ServletRequest for a PortletRequest. The ServletRequest attributes would be shared between all Portlets on the same page and would therefore provide a more accurate "association" mechanism.

        Show
        Ted Goddard added a comment - It may be possible to use reflection to obtain the ServletRequest for a PortletRequest. The ServletRequest attributes would be shared between all Portlets on the same page and would therefore provide a more accurate "association" mechanism.
        Hide
        Deryk Sinotte added a comment -

        I've checked in some changes to the ICEfaces 1.8 trunk core as well as the ossrepo/projects/portletviews/trunk which now allows JBoss Portal to respect multiple tabs/windows opened to the same view. The page id used to group the views together now uses the HttpServletRequest shared by all of the portlets rendered to a page to help uniquely identify a page along with the page name.

        The same logic still needs to be applied for Liferay.

        Show
        Deryk Sinotte added a comment - I've checked in some changes to the ICEfaces 1.8 trunk core as well as the ossrepo/projects/portletviews/trunk which now allows JBoss Portal to respect multiple tabs/windows opened to the same view. The page id used to group the views together now uses the HttpServletRequest shared by all of the portlets rendered to a page to help uniquely identify a page along with the page name. The same logic still needs to be applied for Liferay.
        Hide
        Deryk Sinotte added a comment -

        I've added code to support Liferay having the same behaviour as JBoss. There were some modifications required to the strategy that we are using with Liferay in that Liferay, by default, namespaces request attributes. That means each portlet was getting it's own set of separate request attributes. In order for them to share, I needed to call a more specific method that turned off the namespacing.

        Show
        Deryk Sinotte added a comment - I've added code to support Liferay having the same behaviour as JBoss. There were some modifications required to the strategy that we are using with Liferay in that Liferay, by default, namespaces request attributes. That means each portlet was getting it's own set of separate request attributes. In order for them to share, I needed to call a more specific method that turned off the namespacing.
        Hide
        Deryk Sinotte added a comment -

        I should note that there is a documentation requirement for Liferay. In our code that helps with disposing views, we use a the ThemeDisplay instance provided by Liferay. This attribute is not available unless the following context parameter is set:

        <context-param>
        <param-name>com.icesoft.faces.portlet.hiddenAttributes</param-name>
        <param-value>THEME_DISPLAY</param-value>
        </context-param>

        Show
        Deryk Sinotte added a comment - I should note that there is a documentation requirement for Liferay. In our code that helps with disposing views, we use a the ThemeDisplay instance provided by Liferay. This attribute is not available unless the following context parameter is set: <context-param> <param-name>com.icesoft.faces.portlet.hiddenAttributes</param-name> <param-value>THEME_DISPLAY</param-value> </context-param>

          People

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

            Dates

            • Created:
              Updated:
              Resolved: