[jira] [Closed] (PLUTO-793) TCK: Contesting assumptions of PortletContext.getRealPath(String) in V2EnvironmentTests_PortletContext_ApiRender_getRealPath3

["Neil Griffin (Jira)" <ji...@apache.org>]

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

Neil Griffin closed PLUTO-793.
------------------------------
    Resolution: Fixed

> TCK: Contesting assumptions of PortletContext.getRealPath(String) in V2EnvironmentTests_PortletContext_ApiRender_getRealPath3
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: PLUTO-793
>                 URL: https://issues.apache.org/jira/browse/PLUTO-793
>             Project: Pluto
>          Issue Type: Bug
>          Components: tck
>    Affects Versions: 3.0.2-TCK
>            Reporter: Neil Griffin
>            Assignee: Neil Griffin
>            Priority: Major
>             Fix For: 3.0.3-TCK
>
>
> Section 8.3.1 of the Portlet 3.0 Specification titled "Correspondence between ServletContext and PortletContext methods" states:
> {quote}
> The following methods of the PortletContext should provide the same functionality as the
> methods of the ServletContext of similar name, but applied to the deployed portlet 5 application: getAttribute, getAttributeNames, getInitParameter,
> getInitParameterNames, getMimeType, getResourcePaths, getResourceAsStream,
> getClassLoader, getContextPath, getEffectiveMinorVersion.
> {quote}
> In corresponding fashion, the Javadoc for {{PortletContext.getRealPath(String)}} states:
> {quote}
> 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).
> Parameters:
> path - a String specifying a virtual path
> Returns:
> a String specifying the real path, or null if the transformation cannot be performed.
> {quote}
> As such, the implementation for Apache Pluto simply delegates to the underlying {{ServletContext.getRealPath(String)}}:
> {code:java|title=PortletContextImpl.java}
>     public String getRealPath(String path) {
>         return servletContext.getRealPath(path);
>     }
> {code}
> And the [corresponding Java EE 7 Javadoc for ServletContext.getRealPath(String)|https://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getRealPath-java.lang.String-] states:
> {quote}
> This method returns null if the servlet container is unable to translate the given virtual path to a real path.
> {quote}
> Given that background, the TCK test for V2EnvironmentTests_PortletContext_ApiRender_getRealPath3 looks like the following
> {code:java|title=EnvironmentTests_PortletContext_ApiRender.java}
>     try {
>       String realPath =
>           pc.getRealPath("&^*#\\/V2EnvironmentTests_PortletContext_ApiRender_getMimeType4.invalid");
>       if (realPath == null) {
>         tr18.setTcSuccess(true);
>       } else {
>         tr18.appendTcDetail("Failed because real path is not null but " + realPath);
>       }
>     } catch (Exception e) {
>       tr18.appendTcDetail(e.toString());
>     }
> {code}
> The basic assumption of the test is that leading characters (such as those that are invalid for a filename like {{*}} would cause the underlying {{ServletContext.getRealPath(String)}} to return null. However, the Javadoc does not explicitly say that -- in fact, the Javadoc doesn't even require the "real path" of the file to physically exist.
> This issue is contesting the validity of this test, because it assumes the behavior of the underlying servlet container implementation. In the case of Apache Pluto, that would be Apache Tomcat.
> Case-in-point: When Pluto 3.1.1 was upgraded to Tomcat 8.5.69 via PLUTO-788, this TCK test started to fail. The reason why is because of [Tomcat Bugzilla Issue#56890|https://bz.apache.org/bugzilla/show_bug.cgi?id=56890] in which Tomcat versions 8.5.61 (and above) to automatically prepend a forward slash (/) character to the specified virtual path. It turns out that the lack of a leading forward slash was the only reason for Tomcat's implementation of {{{ServetlContext.getRealPath(String)}} to ever return {{null}}. And this was done in response to [Servlet API Issue#105|https://github.com/eclipse-ee4j/servlet-api/issues/105#issuecomment-734729939], where the Tomcat developer states:
> {quote}
> [I will] update Tomcat to be less strict (Tomcat currently requires a "/")"
> {quote}
> In all my attempts running Pluto with Tomcat 8.5.69, I have not been able to pass a non-null String value to the Pluto {{PortletContext.getRealPath(String)}} method and get {{null}} as a return value.
> The only way I can get it to return {{null}} is by passing {{null}}. In order to fix the problem, I will modify TCK test to pass {{null}}, but that might also be an assumption of the behavior of the underlying servlet container implementation.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)