liferay-faces-2.1.5-ga6, liferay-faces-2.2.5-ga6, liferay-faces-3.0.5-legacy-ga6, liferay-faces-3.0.5-ga6, liferay-faces-3.1.5-ga6, liferay-faces-3.2.5-ga6, liferay-faces-4.2.5-ga6
This issue is closely related to
FACES-1224 which was a failure with TCK TestPage159: getRequestServletPathTest.
The TCK defines the following explicit extension-mapped servlet-mapping entries in WEB-INF/web.xml:
<servlet-mapping> <servlet-name>faces</servlet-name> <url-pattern>*.jsf</url-pattern> </servlet-mapping>
According to the JSR 329 Spec, the ExternalContext.getRequestServletPath() method must return a value by "determining the servlet mapping of the Faces servlet and constructing the appropriate paths such that they conform to the paths the servlet container generates when processing an http request which targets this view as defined in SRV .3.4 in the Servlet 2.5 specification titled 'Request Path Elements'."
Given the following viewId specified in WEB-INF/portlet.xml for the getRequestServletPathTest:
<init-param> <name>javax.portlet.faces.defaultViewId.view</name> <value>/tests/singleRequestTest.jsp?field1=value1&field2=value2</value> </init-param>
... the return value should be "/tests/singleRequestTest.jsf?field1=value1&field2=value2" but since the bridge ignores the servlet-mapping it returns "/tests/singleRequestTest.jsp?field1=value1&field2=value2"
- is related to
FACES-1224 Failure in TCK TestPage159: getRequestServletPathTest