Major Description
The JavaDoc for PortletContext.getRealPath() states:
Returns a String containing the real path for a given virtual path. For example, the path /index.html returns the absolute file path of the portlet container file system.
The real path returned will be in a form appropriate to the computer and operating system on which the portlet container is running, including the proper path separators. This method returns null if the portlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a .war archive).
In the case of Liferay Portal, WAR artifacts are not unpacked which means it is impossible for the following code in V2EnvironmentTests_PortletContext_ApiRender_getRealPath1 to pass with success:
if (pc.getRealPath(
"/WEB-INF/V2EnvironmentTests_PortletContext_ApiRender_getMimeType1.html") != null) {
tr16.appendTcDetail(pc
.getRealPath("/WEB-INF/V2EnvironmentTests_PortletContext_ApiRender_getMimeType1.html"));
tr16.setTcSuccess(true);
} else {
tr16.appendTcDetail("Failed because real path cannot be determined.");
}
The proposed solution is to introduce the following context parameter into the WEB-INF/web.xml descriptor:
<context-param> <param-name>javax.portlet.portletcontext.GET_REAL_PATH_SUPPORTED</param-name> <param-value>${portletcontext.getrealpath.supported}</param-value> </context-param>
The default value of the Maven property portletcontext.getrealpath.supported would be true, but for the "liferay" profile, the value would be overridden to false.
The test would then be modified to pass if the feature is not supported.