Testing the ICEfaces 4 trunk, I hit a couple of snags just trying to deploy some portlets. The first one is:

Caused by: java.lang.NullPointerException
	at com.liferay.faces.bridge.context.IncongruityContextCompatImpl.getRequestContentLength(IncongruityContextCompatImpl.java:230)
	at com.liferay.faces.bridge.context.ExternalContextCompatImpl.getRequestContentLength(ExternalContextCompatImpl.java:523)
	at org.icefaces.util.EnvUtils.createSessionOnPageLoad(EnvUtils.java:672)
	at org.icefaces.impl.application.SessionAwareResourceHandlerWrapper.isResourceRequest(SessionAwareResourceHandlerWrapper.java:28)

I have a temp fix for this (which I should be able to turn into a real fix) but then I ran into:

Caused by: java.lang.NullPointerException
	at org.icefaces.ace.component.qrcode.generator.QRCodeResourceHandler.extractResourceId(QRCodeResourceHandler.java:88)
	at org.icefaces.ace.component.qrcode.generator.QRCodeResourceHandler.handleResourceRequest(QRCodeResourceHandler.java:55)
	at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:153)
	at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:153)
	at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:153)
	at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:153)
	at javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:153)
	at org.icefaces.impl.push.servlet.ICEpushResourceHandler$ICEpushResourceHandlerImpl.handleResourceRequest(ICEpushResourceHandler.java:229)
	at org.icefaces.impl.push.servlet.ICEpushResourceHandler.handleResourceRequest(ICEpushResourceHandler.java:128)

Don't have anything for this yet.

Went back to the ICEfaces 3.3 maintenance branch and thought I had the same issue with the EnvUtils call but now it seems like it's okay. The same problematic code is present but is not called during the initial page render like it is in ICEfaces 4. The QRCode resource handling code doesn't exist in ICEfaces 3.3 so that isn't a factor.

However, turning on coalescing still impacts certain components under ICEfaces 3.3. maintenance.

Coding around the two issues noted above leads to this:

java.lang.UnsupportedOperationException
	at javax.faces.context.ExternalContext.getClientWindow(ExternalContext.java:1500)
	at javax.faces.context.ExternalContextWrapper.getClientWindow(ExternalContextWrapper.java:530)

This is a 2.2 feature that isn't supported by the bridge. The latest available version of the LiferayFaces Bridge is 3.1.3-ga4. The versioning equation for the bridge is:

3.1.x: (JSF 2.1 + Liferay 6.1)
3.0.x: (JSF 2.1 + Liferay 6.0)
2.1.x: (JSF 1.2 + Liferay 6.1)

Version 4.x will target 2.2 but is not available yet. I'll try the SNAPSHOT version to continue.

It appears that the problem may be similar to that reported in ICE-9338. In that case it was determined that the resource coalescing wasn't working properly when multiple views were involved as resources that required for one portlet but not for another were being removed.

In this case, with coalescing turned on, and the Chart portlet added to the page by itself, everything is fine. If I add certain other portlets to the page the Chart fails to render with a client-side error:

Uncaught TypeError: Cannot read property 'CanvasAxisTickRenderer' of undefined

I verified that the 'jqPlot Charts' JavaScript required for the chart were not included in coalesced.js. This only happens when certain other portlets are added however. For example, having Animation + Charts works fine. But having Context Menu + Charts causes the problem.

Ran some tests to verify where we see the problem. Running icefaces-ee-3.3.0.GA_P01 on Liferay 6.1.1 works. After that it seems that any other combination of ICEfaces (3.3 maintenance branch or 4.0 trunk) and Liferay (6.1.1 or 6.1.2) shows the problem.

Our strategy for coalescing resources across portlets is to store the current collection of resources as a request attribute and then as each portlet processes its resources, it can check it against the other resources to avoid duplicates and ensure nothing is left out. To do this, we had to access the original HttpServletRequest rather than use the PortletRequests or some other scope as the HttpServletRequest was the only artifact that has the proper scope to cover all the portlets on the page. It's a creative solution for a gap in the spec. Sharing data across portlets is generally container specific so our solution was also container specific (we have special code for getting the original HttpServletRequests for various portal implementations).

As of Liferay 6.1.2, they've thrown up a barrier to this technique. The code for getting the original HttpServletRequest, rather than returning a raw Tomcat request now returns com.liferay.portal.kernel.portlet.RestrictPortletServletRequest which guards against the thing we are specifically trying to do. That is, when you add attributes to the request, they are not accessible when you try to get them during processing for the next portlet. So we'll need to come up with yet another strategy to figure out how to carry these resources across the breadth of the page rendering.

Just noticed that this strategy is used in the LiferayOriginalRequestWindowScopeSharing class as well so there's a good chance that WindowScope misbehaves on Liferay 6.1.2 as well.

Resolving as fixed.

In order to use request attributes that span across multiple portlets on the page, we have our own portal-specific code that attempts to get at the original HttpServletRequest rather than use the PortletRequest. From a strict portal sense this behaviour is not encourage which is why we require specific code for different portal containers and even different versions.

In Liferay 6.1.2, they changed the internal request wrapper so in our LiferayOriginalRequestGetter we had to accommodate for this.