You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2004/11/10 19:20:26 UTC

DO NOT REPLY [Bug 32165] New: - FacesRequestProcessor bug when using prefix mapped Struts servlet & extension mapped Faces servlet

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32165>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32165

FacesRequestProcessor bug when using prefix mapped Struts servlet & extension mapped Faces servlet

           Summary: FacesRequestProcessor bug when using prefix mapped
                    Struts servlet & extension mapped Faces servlet
           Product: Struts
           Version: 1.2.4
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Struts-Faces Library
        AssignedTo: dev@struts.apache.org
        ReportedBy: cfraser@ticketweb.com


I've found an extension mapping related bug in the struts-faces
FacesRequestProcessor that is rearing its head when using a prefix mapped Struts
servlet coupled with an extension mapped Faces servlet in Sun's JSF 1.1.01 RI.

I've got a simple scenario where I'm forwarding from a Struts Action to a Faces
View, using the standard org.apache.struts.actions.ForwardAction.  I've verified
that calling the Faces View on its own works just fine.  However, when the
forward to the Faces View executes, the container cannot determine that it is a
Faces request and blows up with an error.  

The declaration in my struts-config.xml is as follows:

<action path="/path/to/struts/Action"
        parameter="/path/to.faces"
        type="org.apache.struts.actions.ForwardAction">

After digging and digging, I've found that extension mapping cannot be detected
unless request.pathInfo() returns null.  And in my case, where the Struts
servlet is prefix mapped and the Faces servlet is extension mapped, things break
down.  The reason being that in
org.apache.struts.faces.application.FacesRequestProcessor.doForward(uri,
request, response), around line 136, the FacesContext is created using the
HttpServletRequest which was passed in to doForward(uri, request, response). 
This seems to work fine, but then around line 150 lifecycle.render(context) is
called and bad things start happening.  

In a nutshell, lifecycle.render(context) calls code which calls code which
eventually calls
com.sun.faces.application.ViewHandlerImpl.getMappingForRequest(servletPath,
pathInfo) using the originating Struts based request, and if you dig into this
method, you'll find these comments (and following code that fulfills them):

        // presence of path info means we were invoked
        // using a prefix path mapping

Now, given that my Struts servlet is prefix mapped, and that the incoming
request is not being manipulated before the view is being rendered, I've got
both a servletPath as well as pathInfo, which results in Sun's ViewHandlerImpl
thinking that the Faces servlet is not being invoked.

To temporarily alleviate my problem, I modified the struts-faces
HttpServletRequestWrapper such that it overrides the pathInfo member and changed
the struts-faces FacesRequestProcessor to use the struts-faces
HttpServletRequestWrapper rather than the request when creating the context.

I know that you are trying to get away from using the struts-faces
HttpServletRequestWrapper, but I see no other way around my problem than to wrap
the request so I can get a handle on some of its properties.  Please let me know
if you have any thoughts on this.

thanks again,
Chris Fraser

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org