myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Sartoris (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Created] (MYFACES-4191) Non-Faces request to Servlet does not return correct path for Resource
Date Fri, 19 Jan 2018 17:37:00 GMT
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)

Mime
View raw message