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