You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Jay Sartoris (JIRA)" <de...@myfaces.apache.org> on 2018/01/19 17:58:00 UTC

[jira] [Updated] (MYFACES-4191) Non-Faces request to Servlet does not return correct path for Resource

     [ https://issues.apache.org/jira/browse/MYFACES-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Sartoris updated MYFACES-4191:
----------------------------------
    Status: Patch Available  (was: Open)

> 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
>            Priority: Major
>         Attachments: MYFACES-4191.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)