ICEfaces
  1. ICEfaces
  2. ICE-8178

Remove dependency on "javax.portlet.faces.bridgeContext" request attribute in FileEntryPhaseListener (was: Remove depedency on "javax.portlet.faces.bridgeContext" request attribute in FileEntryPhaseListener)

          Details

          • Type: Improvement Improvement
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 3.1.0.BETA1
          • Fix Version/s: EE-3.3.0.GA_P02, 4.0
          • Component/s: ACE-Components
          • Labels:
            None
          • Environment:
            Portlets

            Description

            The FileEntryPhaseListener#setPortletRequestWrapper(Object) method contains some workarounds for some things that should be fixed in the bridge. One such hack is getting the BridgeContext instance by calling PortletRequest.getAttribute("javax.portlet.faces.bridgeContext") so that the setPortletRequest(PortletRequest) method can be called.

            I think the latest version of Liferay Faces Bridge may have fixed all the problems that these workarounds are there to solve. In addition, the following issue documents that the "javax.portlet.faces.bridgeContext" request attribute has been deprecated:
            http://issues.liferay.com/browse/FACES-1253

              Activity

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

              Found another place in org/icefaces/util/ClientDescriptor.java where we attempt to get the HttpSession in an unsafe manner. Most of these been corrected previously but a new one snuck in later.

              Show
              Deryk Sinotte added a comment - Found another place in org/icefaces/util/ClientDescriptor.java where we attempt to get the HttpSession in an unsafe manner. Most of these been corrected previously but a new one snuck in later.
              Hide
              Permalink
              Deryk Sinotte added a comment -

              Made it to the point that I can deploy and render a portlet to a page. However, I'm now seeing a "push storm" on the client as soon as the page gets loaded no matter which portlet or example (i.e. both showcase and chat show this behaviour):

              [icepush.a0b63.async-connection] Blocking connection cannot be shared among multiple web-contexts.
Initiating blocking connection for "."  web-context... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1826
[icepush.a0b63] bridge loaded! icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1826
[icepush.a0b63.async-connection] connection monitoring started within window a0b63 icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1826
[icepush.a0b63.async-connection] initialize connection within window a0b63 icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1826
[icepush.a0b63.async-connection] closing previous connection... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63.async-connection] connect... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63] connection will be established in window [a0b63] icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1826
[window] picking updates for view vmt9p9o7 icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63.async-connection] closing previous connection... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63.async-connection] connect... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[window] applied updates >>
eval: //no changes were generated.... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63.async-connection] closing previous connection... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63.async-connection] connect... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63.async-connection] closing previous connection... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63.async-connection] connect... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63.async-connection] closing previous connection... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63.async-connection] connect... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821
[icepush.a0b63.async-connection] closing previous connection...
              Show
              Deryk Sinotte added a comment - Made it to the point that I can deploy and render a portlet to a page. However, I'm now seeing a "push storm" on the client as soon as the page gets loaded no matter which portlet or example (i.e. both showcase and chat show this behaviour): [icepush.a0b63.async-connection] Blocking connection cannot be shared among multiple web-contexts. Initiating blocking connection for "." web-context... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1826 [icepush.a0b63] bridge loaded! icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1826 [icepush.a0b63.async-connection] connection monitoring started within window a0b63 icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1826 [icepush.a0b63.async-connection] initialize connection within window a0b63 icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1826 [icepush.a0b63.async-connection] closing previous connection... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63.async-connection] connect... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63] connection will be established in window [a0b63] icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1826 [window] picking updates for view vmt9p9o7 icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63.async-connection] closing previous connection... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63.async-connection] connect... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [window] applied updates >> eval: //no changes were generated.... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63.async-connection] closing previous connection... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63.async-connection] connect... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63.async-connection] closing previous connection... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63.async-connection] connect... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63.async-connection] closing previous connection... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63.async-connection] connect... icechatter?p_p_id=chaticeportlet_WAR_chatportlet_INSTANCE_z0mgVnwqqFuv&p_p_lifecycle=2&p_p_state=no…:1821 [icepush.a0b63.async-connection] closing previous connection...
              Hide
              Permalink
              Deryk Sinotte added a comment -

              The problem with the push storm is the browser id. In the Browser class, we attempt to get the browser id from the incoming request (either a header or a form parameter). However, it's not showing up in either map which causes the server to generate and respond with a new browser id. This is sent back and the cycle continues. Not sure why we can't pick up the browser id from either location yet. May be related to stricter portlet namespacing behaviour in the bridge.

              Show
              Deryk Sinotte added a comment - The problem with the push storm is the browser id. In the Browser class, we attempt to get the browser id from the incoming request (either a header or a form parameter). However, it's not showing up in either map which causes the server to generate and respond with a new browser id. This is sent back and the cycle continues. Not sure why we can't pick up the browser id from either location yet. May be related to stricter portlet namespacing behaviour in the bridge.
              Hide
              Permalink
              Deryk Sinotte added a comment - - edited

              Got the tip from Neil as noted here:

              https://www.liferay.com/web/neil.griffin/blog/-/blogs/announcement-liferay-faces-3-x-2-x-ga5-released

              The liferay-portlet.xml descriptor requires adding an extra setting to each portlet section to ignore the namespacing requirements:

              <portlet>
        <portlet-name>accordionPanel</portlet-name>
        <instanceable>false</instanceable>
        <requires-namespaced-parameters>false</requires-namespaced-parameters>
        <ajaxable>false</ajaxable>
    </portlet>
              Show
              Deryk Sinotte added a comment - - edited Got the tip from Neil as noted here: https://www.liferay.com/web/neil.griffin/blog/-/blogs/announcement-liferay-faces-3-x-2-x-ga5-released The liferay-portlet.xml descriptor requires adding an extra setting to each portlet section to ignore the namespacing requirements: <portlet> <portlet-name>accordionPanel</portlet-name> <instanceable>false</instanceable> <requires-namespaced-parameters>false</requires-namespaced-parameters> <ajaxable>false</ajaxable> </portlet>
              Hide
              Permalink
              Deryk Sinotte added a comment -

              Resolving as fixed as the dependency on the 'javax.portlet.faces.bridgeContext' request attribute has been removed. I've opened the following cases to address issues found along the way:

              ICE-9954 - Resource coalescing doesn't work with Liferay 6.2
              ICE-9953 - Namespace our parameters
              ICE-9952 - Styling of showcase examples problematic in Liferay 6.2
              PUSH-311 - Push not working with portlets

              Show
              Deryk Sinotte added a comment - Resolving as fixed as the dependency on the 'javax.portlet.faces.bridgeContext' request attribute has been removed. I've opened the following cases to address issues found along the way: ICE-9954 - Resource coalescing doesn't work with Liferay 6.2 ICE-9953 - Namespace our parameters ICE-9952 - Styling of showcase examples problematic in Liferay 6.2 PUSH-311 - Push not working with portlets

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: