The following ResourceHandler classes contain substantial Servlet dependency, but their functionality is not necessarily required for initial Portlet integration:

core/src/main/java/org/icefaces/push/servlet/ICEpushResourceHandler.java
core/src/main/java/org/icefaces/push/servlet/ICEfacesResourceHandler.java

Prior to implementation of JSF-centric resource handling of the URLs (note that this needs to accommodate both extension and path mapped JSF deployments) the Servlet-specific code is now bypassed through delegation in the Portlet case:

if (!(externalContext.getRequest() instanceof HttpServletRequest))

In BridgeSetup, we have the current code commented out followed by code that works with the Portlet Bridge. By converting the resource path into a static String, the Portlet bridge loses its chance to re-write the resource URL in a context dependent way.

// String path = application.getResourceHandler().createResource("bridge.js").getRequestPath();
// UIOutput icefacesCode = new UIOutput();
// icefacesCode.setTransient(true);
// icefacesCode.getAttributes().put("escape", "false");
// icefacesCode.setValue("<script src='" + path + invalidateHTTPCache + "' type='text/javascript'></script>");
// root.addComponentResource(context, icefacesCode, "head");

UIOutput icefacesCode = new UIOutput();
icefacesCode.setTransient(true);
icefacesCode.setRendererType("javax.faces.resource.Script");
icefacesCode.getAttributes().put("name", "bridge.js");
root.addComponentResource(context, icefacesCode, "head");

So, there is not an incompatibility between the SystemEvent mechanism and the Portlet Bridge, but there is an incompatibility with the particular way we were inserting certain resources.

compat FormRenderer as follows appears not to be working in the Portlet example:

hiddenFieldsDiv.setAttribute(HTML.ID_ATTR, uiComponent.getClientId(facesContext) + "hdnFldsDiv");

This may be due to the fact that an h: form rather than an ice: form is being used.

Here is my review of these servlet dependencies as of today, August 21 2010:

• The servlet dependencies in Mojarra still exist, but we've been able to work around them in the bridge

• I never filed a change request with the JSR 314 EG regarding JSF 2.0's getRequestURI() method. As I wrote earlier I've been able to work around it in the bridge. ICEfaces resource requests will just have to make sure that they have ""/javax.faces.resource" in the path in order for the bridge to be able to handle resource requests. Perhaps it would make sense to have something like "/javax.faces.resource/icefaces" so that ICEfaces ResourceHandlers will be able to identify which resources they should be handling, during the chain-of-responsibility.

• Although the comment above says "fixed for ALPHA2," the WindowScopeManager still has servlet API dependencies and was throwing a ClassCastException for me today.

• Regarding the compat FormRenderer, I would think that ice:form would fix the problem.

• I think the code in BridgeSetup.java has been fixed. Looks like resources are being created well in there now.

• The ICEfacesResourceHandler class is no longer present in the trunk, so I guess it's OK!

• package org.icefaces.push.servlet (subject of this email thread) and the ICEpushResourceHandler looks like it has been refactored quite a bit, but it still has some servlet dependencies from what I can see.

As of the Beta 2 release, we have initial support for the Portlet 2 specification (http://jcp.org/en/jsr/detail?id=286). Support is provided by the PortletFaces Bridge (http://www.portletfaces.org/projects/portletfaces-bridge). This version of the bridge is a modified implementation of the Portlet 2.0 Bridge for JavaServer Faces 1.2(http://jcp.org/en/jsr/detail?id=329) but with support for JSF 2.0.

This release version is currently tested and works with Liferay 6.