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

              blocks

              Bug - A problem which impairs or prevents the functions of the product. ICE-2073 ICEfaces AHS: Create only one MessageServiceClient per Servlet Context

              • Major - Major loss of function.
              • Closed

              New Feature - A new feature of the product, which has yet to be developed. ICE-1869 ICEfaces Portlets from different WARs can't co-exist on the same Portal page

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Deryk Sinotte added a comment -

                Assiging to Mircea

                Show
                Deryk Sinotte added a comment - Assiging to Mircea
                Hide
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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
                Permalink
                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: