Neil Griffin created PLUTO-793:
----------------------------------
Summary: 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
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)
