+1<br><br>This one sounds like a no-brainer.<br clear="all">---<br>Kito D. Mann | twitter: kito99 | Author, JSF in Action<br>Virtua, Inc. | <a href="http://www.virtua.com">http://www.virtua.com</a> | JSF/Java EE training and consulting<br>
<a href="http://www.JSFCentral.com">http://www.JSFCentral.com</a> - JavaServer Faces FAQ, news, and info | twitter: jsfcentral<br>+1 203-404-4848 x3<br><br>Sign up for the JSFCentral newsletter: <a href="http://oi.vresp.com/?fid=ac048d0e17">http://oi.vresp.com/?fid=ac048d0e17</a><br>
<br>
<br><br><div class="gmail_quote">On Tue, Apr 6, 2010 at 2:49 AM, Ganesh <span dir="ltr"><<a href="mailto:ganesh@j4fry.org">ganesh@j4fry.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Obviously a must. Can you open a Jira issue at <a href="https://javaserverfaces-spec-public.dev.java.net" target="_blank">https://javaserverfaces-spec-public.dev.java.net</a> and add both the long and short version? Ed goes over them once in a while and classifies them and with this one there is not much to dicuss as JSF portlet compatibility is definitely required.<br>
<br>
Best regards,<br>
Ganesh<br>
<br>
Neil Griffin schrieb:<div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Guys,<br>
<br>
After re-reading my email from Friday, I thought it would be good to provide the short-short version of the story:<br>
<br>
Current resource URLs are not portlet-compatible, i.e.:<br>
<a href="http://localhost:8080/webapp-context/javax.faces.resource/foo?ln=bar" target="_blank">http://localhost:8080/webapp-context/javax.faces.resource/foo?ln=bar</a><br>
<br>
Suggested change for JSF 2.1 that would make the URLs portlet compatible:<br>
<br>
<a href="http://localhost:8080/webapp-context?javax.faces.resource=foo&ln=bar" target="_blank">http://localhost:8080/webapp-context?javax.faces.resource=foo&ln=bar</a><br>
<br>
In other words, I think we need to make javax.faces.resource be a request parameter, rather than part of the path.<br>
<br>
Neil<br>
<br>
On Apr 2, 2010, at 5:21 PM, Neil Griffin wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Guys,<br>
<br>
While developing the portletfaces-bridge [1] I discovered a Servlet-API dependency with the way JSF 2.0 implements detection of resource requests.<br>
<br>
Specifically, javax.faces.application.Resource.getRequestPath() [2] states that "/javax.faces.resource" [3] must be part of the return value of the path.<br>
<br>
Now... it's true that the Javadoc for javax.faces.application.Resource.getRequestPath() [2] adds:<br>
"Make it portlet safe by passing the result through ViewHandler.getResourceURL(javax.faces.context.FacesContext, java.lang.String)" [4]<br>
<br>
... but this isn't good enough. To make a long story short, the Portlet 2.0 API does not provide access to the URL requested by the userAgent/browser. It only provides access to request parameters. So there is no way for a portlet bridge to examine the request path. In fact, the behavior of ExternalContext.getRequestPathInfo() [5] and ExternalContext.getRequestServletPath() [6] are undefined for portlets, because there are no equivalent methods in the javax.portlet.PortletRequest class like there is for javax.servlet.http.HttpServletRequest. So it's just not appropriate for a JSF implementation to rely on them to behave like their Servlet API counterparts.<br>
<br>
Therefore, in order to provide compatibility with portlets, I propose that for JSF 2.1, we deprecate:<br>
- The presence of "/javax.faces.resource/resource-name" in the path<br>
<br>
And change it to this:<br>
- The presence of a "javax.faces.resource" request parameter with value resource-name.<br>
<br>
Using this method, custom implementations of ResourceHandler that are present in component-suites can add additional request parameters to help them identify themselves as a custom resource request.<br>
<br>
Thoughts? I've got it coded up in the bridge and it seems to be working fine.<br>
<br>
Thanks guys,<br>
<br>
Neil<br>
<br>
[1] <a href="http://www.portletfaces.org/projects/portletfaces-bridge" target="_blank">http://www.portletfaces.org/projects/portletfaces-bridge</a><br>
[2] <a href="https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/Resource.html#getRequestPath%28%29" target="_blank">https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/Resource.html#getRequestPath()</a><br>
[3] <a href="https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/ResourceHandler.html#RESOURCE_IDENTIFIER" target="_blank">https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/ResourceHandler.html#RESOURCE_IDENTIFIER</a><br>
[4] <a href="https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/ViewHandler.html#getResourceURL%28javax.faces.context.FacesContext" target="_blank">https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/ViewHandler.html#getResourceURL(javax.faces.context.FacesContext</a>, java.lang.String)<br>
[5] <a href="https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getRequestPathInfo%28%29" target="_blank">https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getRequestPathInfo()</a><br>
[6] <a href="https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getRequestServletPath%28%29" target="_blank">https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getRequestServletPath()</a><br>
<br>
</blockquote>
<br>
</blockquote>
<br></div></div><font color="#888888">
-- <br>
"There are two kinds of people in the world, those who believe there are two kinds of people and those who don't."<br>
— Robert Benchley<br>
</font></blockquote></div><br>