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
              Hide
              Permalink
              Deryk Sinotte added a comment -

              I'll take a look. Since we probably have to work with both PortletFaces and Liferay Faces Bridge for some set of future releases, it may not be possible to remove the workarounds, however.

              Show
              Deryk Sinotte added a comment - I'll take a look. Since we probably have to work with both PortletFaces and Liferay Faces Bridge for some set of future releases, it may not be possible to remove the workarounds, however.
              Hide
              Permalink
              Ken Fyten added a comment -

              Reconsider for 3.2.

              Show
              Ken Fyten added a comment - Reconsider for 3.2.
              Hide
              Permalink
              Mark Collette added a comment -

              To work with both, should we first try to reflectively call BridgeContext.getCurrentInstance, and if that doesn't work then fall-back to trying to access the "javax.portlet.faces.bridgeContext" request attribute? In all cases should we be trying to call setPortletRequest, or is that unnecessary in one of the scenarios?

              Show
              Mark Collette added a comment - To work with both, should we first try to reflectively call BridgeContext.getCurrentInstance, and if that doesn't work then fall-back to trying to access the "javax.portlet.faces.bridgeContext" request attribute? In all cases should we be trying to call setPortletRequest, or is that unnecessary in one of the scenarios?
              Hide
              Permalink
              Neil Griffin added a comment -

              Actually, it would be nice if the bridge workarounds could be removed from ICEfaces and fixed in the bridge. But if you need to rely on BridgeContext, then yes, first reflectively call BridgeContext.getCurrentInstance() then try the attribute.

              Show
              Neil Griffin added a comment - Actually, it would be nice if the bridge workarounds could be removed from ICEfaces and fixed in the bridge. But if you need to rely on BridgeContext, then yes, first reflectively call BridgeContext.getCurrentInstance() then try the attribute.
              Hide
              Permalink
              Deryk Sinotte added a comment -

              Running ICEfaces 4.0 on Liferay 6.2 with the LiferayFaces Bridge 4.2.0-m1 release. There are a few hurdles to getting things to the point where I can test the changes to the FileEntryResourceHandler. First thing is that the pom.xml has to be upgraded to use the correct version of the bridge. Second, maven is having trouble compiling some files that have special characters but were saved to the repository in a non-UTF8 format:

              samples/showcase/example/ace/combobox/ComboBoxBean.java
              samples/showcase/example/ace/combobox/ComboBoxFilteringBean.java
              samples/showcase/example/ace/selectmenu/SelectMenuBean.java
              samples/showcase/example/ace/simpleselectonemenu/SimpleSelectOneMenuBean.java

              These all contain an entry for "Trois Riviéres" but the accented character isn't encoded as UTF-8. Building with Ant appears to work because our compile target specifies:

              encoding="ISO-8859-1"

              So I'm changing the Maven compiler plugin to use the same encoding for the samples.

              Show
              Deryk Sinotte added a comment - Running ICEfaces 4.0 on Liferay 6.2 with the LiferayFaces Bridge 4.2.0-m1 release. There are a few hurdles to getting things to the point where I can test the changes to the FileEntryResourceHandler. First thing is that the pom.xml has to be upgraded to use the correct version of the bridge. Second, maven is having trouble compiling some files that have special characters but were saved to the repository in a non-UTF8 format: samples/showcase/example/ace/combobox/ComboBoxBean.java samples/showcase/example/ace/combobox/ComboBoxFilteringBean.java samples/showcase/example/ace/selectmenu/SelectMenuBean.java samples/showcase/example/ace/simpleselectonemenu/SimpleSelectOneMenuBean.java These all contain an entry for "Trois Riviéres" but the accented character isn't encoded as UTF-8. Building with Ant appears to work because our compile target specifies: encoding="ISO-8859-1" So I'm changing the Maven compiler plugin to use the same encoding for the samples.
              Hide
              Permalink
              Deryk Sinotte added a comment -

              Next up, when deploying the showcase, I was seeing the following for every managed bean in the showcase-portlet example:

              WARNING: JSF1074: Managed bean named 'menuButtonBean' has already been registered. Replacing existing managed bean class type org.icefaces.samples.showcase.example.ace.menuButton.MenuButtonBean with org.icefaces.samples.showcase.example.ace.menuButton.MenuButtonBean.

              Attempting to add the FileEntry portlet to a page would cause it to complain with:

              javax.faces.FacesException: Cannot add the same component twice: fileEntry_WAR_showcaseportlet:example-form:ice_fileEntry_encodedURL
              at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:510)
              at com.sun.faces.context.StateContext$AddRemoveListener.handleAdd(StateContext.java:437)

              So it looks like it was doing everything twice. Turns out that we had a workaround in the web.xml files from a previous version of the LiferayFaces Bridge where we had to manually add some listeners:

               <!-- Specifying these listeners in this order as per http://issues.liferay.com/browse/FACES-1511.  Remove if you
         are not using both the LiferayFaces Bridge and Mojarra. -->
    <listener>
    	<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
    </listener>

    <listener>
    	<listener-class>com.liferay.faces.bridge.servlet.BridgeSessionListener</listener-class>
    </listener>

              Removing these from the web.xml helped get rid of this issue.

              Show
              Deryk Sinotte added a comment - Next up, when deploying the showcase, I was seeing the following for every managed bean in the showcase-portlet example: WARNING: JSF1074: Managed bean named 'menuButtonBean' has already been registered. Replacing existing managed bean class type org.icefaces.samples.showcase.example.ace.menuButton.MenuButtonBean with org.icefaces.samples.showcase.example.ace.menuButton.MenuButtonBean. Attempting to add the FileEntry portlet to a page would cause it to complain with: javax.faces.FacesException: Cannot add the same component twice: fileEntry_WAR_showcaseportlet :example-form:ice_fileEntry_encodedURL at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:510) at com.sun.faces.context.StateContext$AddRemoveListener.handleAdd(StateContext.java:437) So it looks like it was doing everything twice. Turns out that we had a workaround in the web.xml files from a previous version of the LiferayFaces Bridge where we had to manually add some listeners: <!-- Specifying these listeners in this order as per http://issues.liferay.com/browse/FACES-1511. Remove if you are not using both the LiferayFaces Bridge and Mojarra. --> <listener> <listener-class>com.sun.faces.config.ConfigureListener</listener-class> </listener> <listener> <listener-class>com.liferay.faces.bridge.servlet.BridgeSessionListener</listener-class> </listener> Removing these from the web.xml helped get rid of this issue.
              Hide
              Permalink
              Deryk Sinotte added a comment -

              Once past the above issue, it appears that resource coalescing was leading to a stack overflow:

              Caused by: java.lang.OutOfMemoryError: Java heap space
	at java.util.zip.InflaterInputStream.<init>(InflaterInputStream.java:88)
	at java.util.zip.ZipFile$ZipFileInflaterInputStream.<init>(ZipFile.java:387)
	at java.util.zip.ZipFile.getInputStream(ZipFile.java:368)
	at java.util.jar.JarFile.getInputStream(JarFile.java:409)
	at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:162)
	at java.net.URL.openStream(URL.java:1037)
	at org.apache.catalina.loader.WebappClassLoader.findLoadedResource(WebappClassLoader.java:3273)
	at org.apache.catalina.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1481)
	at com.sun.faces.application.resource.ClasspathResourceHelper.getNonCompressedInputStream(ClasspathResourceHelper.java:154)
	at com.sun.faces.application.resource.ResourceHelper.getInputStreamFromClientInfo(ResourceHelper.java:267)
	at com.sun.faces.application.resource.ResourceHelper.getInputStream(ResourceHelper.java:179)
	at com.sun.faces.application.resource.ResourceImpl.getInputStream(ResourceImpl.java:178)
	at javax.faces.application.ResourceWrapper.getInputStream(ResourceWrapper.java:88)
	at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63)
	at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63)
	at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63)
	at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63)
	at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63)
	at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63)
	at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63)
	at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63)
	at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63)
	at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63)
...

              Not sure how to fix this yet or what's causing it but turning off resource coalescing allows us to move forward.

              Show
              Deryk Sinotte added a comment - Once past the above issue, it appears that resource coalescing was leading to a stack overflow: Caused by: java.lang.OutOfMemoryError: Java heap space at java.util.zip.InflaterInputStream.<init>(InflaterInputStream.java:88) at java.util.zip.ZipFile$ZipFileInflaterInputStream.<init>(ZipFile.java:387) at java.util.zip.ZipFile.getInputStream(ZipFile.java:368) at java.util.jar.JarFile.getInputStream(JarFile.java:409) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:162) at java.net.URL.openStream(URL.java:1037) at org.apache.catalina.loader.WebappClassLoader.findLoadedResource(WebappClassLoader.java:3273) at org.apache.catalina.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1481) at com.sun.faces.application.resource.ClasspathResourceHelper.getNonCompressedInputStream(ClasspathResourceHelper.java:154) at com.sun.faces.application.resource.ResourceHelper.getInputStreamFromClientInfo(ResourceHelper.java:267) at com.sun.faces.application.resource.ResourceHelper.getInputStream(ResourceHelper.java:179) at com.sun.faces.application.resource.ResourceImpl.getInputStream(ResourceImpl.java:178) at javax.faces.application.ResourceWrapper.getInputStream(ResourceWrapper.java:88) at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63) at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63) at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63) at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63) at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63) at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63) at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63) at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63) at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63) at org.icefaces.impl.application.CoalescingResource.getInputStream(CoalescingResource.java:63) ... Not sure how to fix this yet or what's causing it but turning off resource coalescing allows us to move forward.
              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: