[ 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)