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

[Neil Griffin]

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/application/ResourceWrapper.html#getRequestPath()


> On Jan 13, 2010, at 1:07 PM, Lincoln Baxter, III wrote:
>> 
> Sorry. Hard to type on the phone. I was speaking specifically about externalcontext.getrequestpath()
> 
> The resource.getrequestpath() method states no such requirement. It may be an oversight.
> 
> Lincoln Baxter III
> http://ocpsoft.com
> http://scrumshark.com
> Keep it simple.
> 

On Jan 13, 2010, at 12:50 PM, Neil Griffin wrote:

> Thanks Lincoln. Well if that's indeed the case, then I guess that means there are some bugs in Mojarra. For example, StyleSheetRenderer.encodeEnd(FacesContext, UIComponent) should call ExternalContext.encodeResourceURL() before it outputs the <link> tag.
> 
> Anyone from the Mojarra team agree/disagree?
> 
> Neil
> 
> On Jan 13, 2010, at 12:43 PM, Lincoln Baxter, III wrote:
> 
>> I believe it is your responsibility, since that method is required to simply pass-through the servlet/portletrequest return value for that method.
>> 
>> Lincoln Baxter III
>> http://ocpsoft.com
>> http://scrumshark.com
>> Keep it simple.
>> 
>> 
>>> On Jan 13, 2010 12:18 PM, "Neil Griffin" <neil.griffin at portletfaces.org> wrote:
>>> 
>>> Hello all,
>>> 
>>> This could be a bug in Mojarra 2.0.2, or it could be a problem with the spec -- I'm not sure. Someone please help me out. :-)
>>> 
>>> I'm trying to get JSF 2.0 resource stuff to work right in the PortletFaces Bridge, but the return value from Resource.getRequestPath() is not encoded...
>>> 
>>> So the question is... who's responsibility is it to call ExternalContext.encodeResourceURL()? Should that already be done by Resource.getRequestPath(), or should the calling method  (like StyleSheetRenderer.encodeEnd(FacesContext, UIComponent) take care of it?
>>> 
>>> Thanks,
>>> 
>>> Neil
>>> 
>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100115/38f63c7f/attachment.html