Re: [jsr-314-open] Problem with Resource.getRequestPath() in a portlet environment

FYI, I tried this and bad things started to happen: public class MyResourceImpl extends javax.faces.application.ResourceWrapper { @Override public String getRequestPath() { ExternalContext externalContext = FacesContext.getCurrentInstance.getExternalContext(); return externalContext.encodeResourceURL(getWrapped().getRequestPath()); } } So at this point I would say three things: 1. Mojarra's implementation of ResourceImpl.getRequestPath() is fine -- don't change it. Portlet bridges can work with the return value -- they just have to parse out the request parameters and make them work with a javax.portlet.ResourceURL 2. The Javadocs for Resource.getRequestPath() [1] should be fortified to explicitly say that this method should: A. Construct a String-based URI that includes the ResourceHandler.RESOURCE_IDENTIFIER (aka "javax.faces.resource") B. Add request parameters to the URL for: i. Resource Name ii. Library Name iii. Library Version iv. Locale Prefix C. Call ViewHander.getResourceURL(uri) to obtain a URL and return that value D. It is the responsibility of the caller to call ExternalContext.encodeResourceURL(String) on the return value before rendering the URL in the response 3. Since the following classes in Mojarra call Resource.getRequestPath(), they should get fixed so that they call ExternalContext.encodeResourceURL(String): com.sun.faces.el.ResourceELResolver com.sun.faces.renderkit.html_basic.ScriptRenderer com.sun.faces.renderkit.html_basic.StylesheetRenderer com.sun.faces.renderkit.RenderKitUtils Anyone from the Mojarra team agree/disagree? Thanks, Neil [1] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/... On Jan 13, 2010, at 12:50 PM, Neil Griffin wrote: