Obviously a must. Can you open a Jira issue at
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