myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Nicolucci (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Commented] (MYFACES-4191) Non-Faces request to Servlet does not return correct path for Resource
Date Fri, 19 Jan 2018 21:55:00 GMT

    [ https://issues.apache.org/jira/browse/MYFACES-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332936#comment-16332936
] 

Paul Nicolucci commented on MYFACES-4191:
-----------------------------------------

Thanks to Jay Sartoris for the patch!

> Non-Faces request to Servlet does not return correct path for Resource
> ----------------------------------------------------------------------
>
>                 Key: MYFACES-4191
>                 URL: https://issues.apache.org/jira/browse/MYFACES-4191
>             Project: MyFaces Core
>          Issue Type: Bug
>    Affects Versions: 2.3.0-beta
>            Reporter: Jay Sartoris
>            Assignee: Paul Nicolucci
>            Priority: Major
>             Fix For: 2.3.0
>
>         Attachments: MYFACES-4191-v2.patch, MyFaces_mapping.war
>
>
> If a Non-Faces request to a Servlet creates a Faces Response, the path to a resource
does not contain the correct mapping.  
> I've attached a sample application to show how to reproduce this issue.  
> A servlet acquires the FacesContext as described in Section 2.4.1.2 of the JSF 2.3 spec.
 
> Then, the servlet gets the ResourceHandler and creates a Resource to a .gif file.  
> On this resulting Resource object, I call getRequestPath(), however the path returned
is not the one I expected. 
> For example, in the sample app provided, access this URL:
> localhost:8080/MyFaces23_mapping/TestServlet
> The getRequestPath returned is 
> /MyFaces23_mapping/faces/javax.faces.resource/MyFaces.gif
> However, the path that should be returned is:
> /MyFaces23_mapping/TestServlet/javax.faces.resource/MyFaces.gif
> The reason for this is the algorithm in the org.apache.myfaces.shared.application.FacesServletMappingUtils.createMappingFromServletRegistration()
method.  This is new to MyFaces 2.3.  The mapping to the Servlet (TestServlet) is ignored
since there is a mapping to the FacesServlet (/faces/*) in the web.xml. Since there is a mapping
to the FacesServlet, that is the value returned for the mapping.  
> The code path for this scenario begins with org.apache.myfaces.shared.resource.BaseResourceHandlerSupport.getFacesServletMapping()
> The context attributes does not have a value for CACHED_SERVLET_MAPPING on the first
pass through so it calls org.apache.myfaces.shared.application.FacesServletMappingUtils.calculateGenericFacesServletMapping(). 
In there we end up calling FacesServletMappingUtils.createMappingFromServletRegistration()
and the wrong mapping is returned.  
> This did not occur in MyFaces 2.2.  In there, MyFaces just called FacesServletMapping.createPrefixMapping
and the TestServlet mapping was returned.  Also, this worked on Mojarra JSF 2.3 (2.3.3) as
well.
> There is no issue on MyFaces 2.3 with an extension mapping.  In my opionion, the code
needs to take in to account the servletPath in createMappingFromServletRegistration.  If
the Servlet Mapping (/TestServlet) matches the servletPath that is passed in, then we should
return that.  
> I'm uploading a patch for this issue as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message