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
              Neil Griffin created issue -
              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.
              Deryk Sinotte made changes -
              Field Original Value New Value
              Salesforce Case []
              Fix Version/s 3.1 [ 10312 ]
              Assignee Deryk Sinotte [ deryk.sinotte ]
              Ken Fyten made changes -
              Salesforce Case []
              Fix Version/s 3.1.0.RC1 [ 10337 ]
              Ken Fyten made changes -
              Fix Version/s 3.1.0.RC1 [ 10337 ]
              Hide
              Permalink
              Ken Fyten added a comment -

              Reconsider for 3.2.

              Show
              Ken Fyten added a comment - Reconsider for 3.2.
              Ken Fyten made changes -
              Salesforce Case []
              Fix Version/s 3.2 [ 10338 ]
              Fix Version/s 3.1 [ 10312 ]
              Migration made changes -
              Assignee Priority P3 [ 10012 ]
              Migration made changes -
              Summary Remove depedency on "javax.portlet.faces.bridgeContext" request attribute in FileEntryPhaseListener Remove dependency on "javax.portlet.faces.bridgeContext" request attribute in FileEntryPhaseListener (was: Remove depedency on "javax.portlet.faces.bridgeContext" request attribute in FileEntryPhaseListener)
              Ken Fyten made changes -
              Fix Version/s 3.3 [ 10370 ]
              Fix Version/s 3.2 [ 10338 ]
              Ken Fyten made changes -
              Assignee Deryk Sinotte [ deryk.sinotte ] Mark Collette [ mark.collette ]
              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.
              Ken Fyten made changes -
              Fix Version/s 3.4 [ 10770 ]
              Fix Version/s 3.3 [ 10370 ]
              Ken Fyten made changes -
              Assignee Mark Collette [ mark.collette ]
              Assignee Priority P3 [ 10012 ]
              Fix Version/s 4.0.BETA [ 10770 ]
              Ken Fyten made changes -
              Assignee Deryk Sinotte [ deryk.sinotte ]
              Fix Version/s 4.0 [ 11382 ]
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #40440 Thu Mar 27 11:35:43 MDT 2014 deryk.sinotte ICE-8178: update poms to use recommended version of LiferayFaces Bridge and to use the same encoding as Ant when compiling files with Trois Riviere (ISO-8859-1 instead of UTF-8)
              Files Changed
              Commit graph MODIFY /icefaces4/trunk/icefaces/samples/pom.xml
              Commit graph MODIFY /icefaces4/trunk/icefaces/pom.xml
              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.
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #40441 Thu Mar 27 11:45:28 MDT 2014 deryk.sinotte ICE-8178: remove old bridge listeners and turn off resource coalescing for portlet examples
              Files Changed
              Commit graph MODIFY /icefaces4/trunk/icefaces/samples/showcase/showcase-portlet/src/main/webapp/WEB-INF/web.xml
              Commit graph MODIFY /icefaces4/trunk/icefaces/samples/core/chat-portlet/src/main/webapp/WEB-INF/web.xml
              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.
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #40442 Thu Mar 27 11:48:21 MDT 2014 deryk.sinotte ICE-8178: use safe method for retrieving the session so that portlets don't blow up
              Files Changed
              Commit graph MODIFY /icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/util/ClientDescriptor.java
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #40451 Thu Mar 27 14:16:26 MDT 2014 deryk.sinotte ICE-8178: update Liferay config files
              Files Changed
              Commit graph MODIFY /icefaces4/trunk/icefaces/samples/core/chat-portlet/src/main/webapp/WEB-INF/portlet.xml
              Commit graph MODIFY /icefaces4/trunk/icefaces/samples/core/chat-portlet/src/main/webapp/WEB-INF/liferay-portlet.xml
              Commit graph MODIFY /icefaces4/trunk/icefaces/samples/core/chat-portlet/src/main/webapp/WEB-INF/liferay-display.xml
              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.
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #40475 Thu Mar 27 18:03:15 MDT 2014 deryk.sinotte ICE-8178: turn off the namespacing requirement for all portlets
              Files Changed
              Commit graph MODIFY /icefaces4/trunk/icefaces/samples/showcase/showcase-portlet/src/main/webapp/WEB-INF/liferay-portlet.xml
              Commit graph MODIFY /icefaces4/trunk/icefaces/samples/core/chat-portlet/src/main/webapp/WEB-INF/liferay-portlet.xml
              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>
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #40478 Fri Mar 28 11:31:40 MDT 2014 deryk.sinotte ICE-8178: implement getPart* methods in our ProxyHttpServletRequest to allow FileEntryResourceHandler to work and remove the check for the deprecated 'javax.portlet.faces.bridgeContext' attribute as noted in the original description of the case
              Files Changed
              Commit graph MODIFY /icefaces4/trunk/icefaces/ace/component/src/org/icefaces/ace/component/fileentry/FileEntryResourceHandler.java
              Commit graph MODIFY /icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/impl/push/servlet/ProxyHttpServletRequest.java
              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
              Deryk Sinotte made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Ken Fyten made changes -
              Resolution Fixed [ 1 ]
              Status Resolved [ 5 ] Reopened [ 4 ]
              Ken Fyten made changes -
              Fix Version/s EE-3.3.0.GA_P02 [ 11371 ]
              Ken Fyten made changes -
              Status Reopened [ 4 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]

                People

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

                  Dates

                  • Created:
                    Updated:
                    Resolved: