It should be possible for the PortletFaces Bridge to detect that it is serving a non-Portlet request and delegate to the JSF factory chain for this request.

Addition of the Servlet path to the PortletFaces bridge is expected to fix resource dispatching issues for outputResource, chart, and richText.

Is there a reason why we can't let the portlet RESOURCE_PHASE handle the resource requests, like we do for jsf.js?

This would require modifying the URLs to be compatible with the Portlet URLs – this is to handle legacy code in ICEfaces 2.0 compat where it is difficult to change how the URLs are generated.

Would it be possible to have /javax.faces.resource/icefaces in the resource URL instead of /icefaces/resource? That would invoke the standard resource handling found in BridgeImpl.doFacesRequest(ResourceRequest, ResourceResponse) and delegate to the ICEfaces 2.0 ResourceHandler via the chain-of-responsibility pattern.

http://svn.portletfaces.org/svn/portletfaces/bridge/org.portletfaces.bridge.impl/trunk/src/main/java/org/portletfaces/bridge/BridgeImpl.java

Would that actually work? From the BridgeImpl code it looks like a PortletRequest is expected for all the methods. The problem we're having is that a Servlet request is being handled by FacesServlet so org.portletfaces.bridge.context.ExternalContextFactoryImpl.getExternalContext() should delegate to the parent factory.

It should have access to that parent factory as part of the getWrapped() implementation:

http://download.oracle.com/javaee/6/api/javax/faces/context/ExternalContextFactory.html

After talking with Ted, I came to understand that requests to the FacesServlet can occur in a portlet environment if a compatibility component has dependencies on relative URLs for resources. He recommended that I take advantage of the decorator pattern of ExternalContextFactory and delegate if the incoming request is not an instanceof PortletRequest.

Commit: Committed revision 81 (1 entry) BETA1-SNAPSHOT
http://svn.portletfaces.org/svn/portletfaces/bridge/org.portletfaces.bridge.impl/trunk/src/main/java/org/portletfaces/bridge/context/ExternalContextFactoryImpl.java

Assigning to Deryk to verify if this allows additional component-showcase portlets to work.

Resolving this as fixed. In running the Rich Input Text example as a portlet, there are a couple of script resources that are downloaded dynamically with URL's that look like this:

http://localhost:8080/component-showcase-portlet/icefaces/resource/LTc4NTk0MDYzMQ==/

The result is that they are properly retrieved:

Request URL:http://localhost:8080/component-showcase-portlet/icefaces/resource/LTc4NTk0MDYzMQ==/
Request Method:GET
Status Code:200 OK

These script resources are successfully retrieved and the portlet is functional.