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:37:00 UTC

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

Jay Sartoris created MYFACES-4191:
-------------------------------------

             Summary: 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
         Attachments: 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)