ICEfaces
  1. ICEfaces
  2. ICE-1675

Framework specific ID (ICEfaces ID and view number) handling breaks multiple portlets on a page

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6DR#5
    • Fix Version/s: 1.7DR#3, 1.7
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Portlet
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.)

      Description

      Our current handling of ICEfaces IDs and view numbers causes problems when there are multiple ICEfaces portlets on a page served from separate archives. The problem stems from the fact that ICEfaces IDs and view numbers are not generated based on the session, which is shared between multiple portlets on a page. Instead, these framework specific IDs are generated per servlet, which are NOT shared between portlets when those portlets are served from separate deployment archives (war files).

      So there are at least two things that probably need to be done:

      1) The generation of ICEfaces IDs must be session specific. That is, portlets that may be deployed as separate web apps but could potentially share a session so the ICEfaces ID must be generated and stored in reference to that shared session to ensure that additional communication is properly directed.

      2) View numbers generation needs to be unique to the session to avoid view number collisions in portlets served from separate deployment archives.

        Issue Links

          Activity

          Hide
          Deryk Sinotte added a comment -

          Assiging to Mircea

          Show
          Deryk Sinotte added a comment - Assiging to Mircea
          Hide
          Ken Fyten added a comment -

          This might be related to ICE-1869.

          Show
          Ken Fyten added a comment - This might be related to ICE-1869 .
          Hide
          Mircea Toma added a comment -

          In order to fix this issue there are a few steps we have to take:

          a) We need to get away from instantiating one bridge instance per window. When running in a portlet environment each portlet running ICEfaces will instantiate a bridge instance that will receive its own configuration containing session id (icefacesID), context paths, operation mode...

          b) Understand how Liferay and other portals are mapping the portlet sessions to servlet sessions when portlets are in different wars. Also understand how context paths are re-mapped.

          c) For asynchronous mode since we have the restriction of one blocking connection per DNS domain but there are multiple sessions (portlet/servlet?) running we need to introduce a separate server-side service that handles the blocking/persistent connection. This service will be used all the running sessions to send updates back to the client. This service will act similarly to the AsynchronousServer but all the communication should be intra-VM.

          Show
          Mircea Toma added a comment - In order to fix this issue there are a few steps we have to take: a) We need to get away from instantiating one bridge instance per window. When running in a portlet environment each portlet running ICEfaces will instantiate a bridge instance that will receive its own configuration containing session id (icefacesID), context paths, operation mode... b) Understand how Liferay and other portals are mapping the portlet sessions to servlet sessions when portlets are in different wars. Also understand how context paths are re-mapped. c) For asynchronous mode since we have the restriction of one blocking connection per DNS domain but there are multiple sessions (portlet/servlet?) running we need to introduce a separate server-side service that handles the blocking/persistent connection. This service will be used all the running sessions to send updates back to the client. This service will act similarly to the AsynchronousServer but all the communication should be intra-VM.
          Hide
          Mike Lawrence added a comment -

          Please consider the use of the Tomcat server.xml setting
          emptySessionPath="true"
          which my be required to run portals in a context other than ROOT.
          This can cause cookies from portlets loaded from different wars to collide if the
          cookie names are not unique (eg prepending the war name would make the cookie name unique)

          I believe this bug is a duplicate of ICE-1869 as Ken mentioned above.

          Show
          Mike Lawrence added a comment - Please consider the use of the Tomcat server.xml setting emptySessionPath="true" which my be required to run portals in a context other than ROOT. This can cause cookies from portlets loaded from different wars to collide if the cookie names are not unique (eg prepending the war name would make the cookie name unique) I believe this bug is a duplicate of ICE-1869 as Ken mentioned above.
          Hide
          Mircea Toma added a comment -

          Segregate context path configuration to integrate with a singleton async-server.

          Show
          Mircea Toma added a comment - Segregate context path configuration to integrate with a singleton async-server.
          Hide
          Mircea Toma added a comment -

          Added 'com.icesoft.faces.asyncServerContext' context parameter used to specify the name of async-server's context.

          Show
          Mircea Toma added a comment - Added 'com.icesoft.faces.asyncServerContext' context parameter used to specify the name of async-server's context.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: