Hi Guys, While developing the portletfaces-bridge [1] I discovered a Servlet-API dependency with the way JSF 2.0 implements detection of resource requests. Specifically, javax.faces.application.Resource.getRequestPath() [2] states that "/javax.faces.resource" [3] must be part of the return value of the path. Now... it's true that the Javadoc for javax.faces.application.Resource.getRequestPath() [2] adds: "Make it portlet safe by passing the result through ViewHandler.getResourceURL(javax.faces.context.FacesContext, java.lang.String)" [4] ... 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. Therefore, in order to provide compatibility with portlets, I propose that for JSF 2.1, we deprecate: - The presence of "/javax.faces.resource/resource-name" in the path And change it to this: - The presence of a "javax.faces.resource" request parameter with value resource-name. 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. Thoughts? I've got it coded up in the bridge and it seems to be working fine. Thanks guys, Neil [1] http://www.portletfaces.org/projects/portletfaces-bridge [2] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/... [3] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/... [4] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/..., java.lang.String) [5] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/... [6] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/...

Obviously a must. Can you open a Jira issue at https://javaserverfaces-spec-public.dev.java.net 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. Best regards, Ganesh Neil Griffin schrieb: Hi Guys, > > After re-reading my email from Friday, I thought it would be good to > provide the short-short version of the story: > > Current resource URLs are not portlet-compatible, i.e.: > > http://localhost:8080/webapp-context/javax.faces.resource/foo?ln=bar > > Suggested change for JSF 2.1 that would make the URLs portlet compatible: > > > http://localhost:8080/webapp-context?javax.faces.resource=foo&ln=bar > > In other words, I think we need to make javax.faces.resource be a request > parameter, rather than part of the path. > > Neil > > On Apr 2, 2010, at 5:21 PM, Neil Griffin wrote: > > Hi Guys, >> >> While developing the portletfaces-bridge [1] I discovered a Servlet-API >> dependency with the way JSF 2.0 implements detection of resource requests. >> >> Specifically, javax.faces.application.Resource.getRequestPath() [2] >> states that "/javax.faces.resource" [3] must be part of the return value of >> the path. >> >> Now... it's true that the Javadoc for >> javax.faces.application.Resource.getRequestPath() [2] adds: >> "Make it portlet safe by passing the result through >> ViewHandler.getResourceURL(javax.faces.context.FacesContext, >> java.lang.String)" [4] >> >> ... 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. >> >> Therefore, in order to provide compatibility with portlets, I propose >> that for JSF 2.1, we deprecate: >> - The presence of "/javax.faces.resource/resource-name" in the >> path >> >> And change it to this: >> - The presence of a "javax.faces.resource" request parameter with >> value resource-name. >> >> 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. >> >> Thoughts? I've got it coded up in the bridge and it seems to be working >> fine. >> >> Thanks guys, >> >> Neil >> >> [1] http://www.portletfaces.org/projects/portletfaces-bridge >> [2] >> https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/... >> [3] >> https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/... >> [4] >> https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/...;, >> java.lang.String) >> [5] >> https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/... >> [6] >> https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/... >> >> > -- "There are two kinds of people in the world, those who believe there are two kinds of people and those who don't." — Robert Benchley