[jsr-314-open-mirror] [jsr-314-open] Servlet-API dependency with resources

Kito Mann kito.mann at virtua.com
Tue Apr 6 22:31:50 EDT 2010


+1

This one sounds like a no-brainer.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3

Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17



On Tue, Apr 6, 2010 at 2:49 AM, Ganesh <ganesh at j4fry.org> wrote:

> 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/application/Resource.html#getRequestPath()<https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/Resource.html#getRequestPath%28%29>
>>> [3]
>>> https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/ResourceHandler.html#RESOURCE_IDENTIFIER
>>> [4]
>>> https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/ViewHandler.html#getResourceURL(javax.faces.context.FacesContext<https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/application/ViewHandler.html#getResourceURL%28javax.faces.context.FacesContext>,
>>> java.lang.String)
>>> [5]
>>> https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getRequestPathInfo()<https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getRequestPathInfo%28%29>
>>> [6]
>>> https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getRequestServletPath()<https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#getRequestServletPath%28%29>
>>>
>>>
>>
> --
> "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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100406/7904f6ce/attachment-0002.html 


More information about the jsr-314-open-mirror mailing list