You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2011/09/11 01:37:43 UTC
DO NOT REPLY [Bug 51799] New:
servletContext.getRealPath("/someFolderThatDoesNotExist/") should return null
https://issues.apache.org/bugzilla/show_bug.cgi?id=51799
Bug #: 51799
Summary: servletContext.getRealPath("/someFolderThatDoesNotExis
t/") should return null
Product: Tomcat 7
Version: 7.0.21
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Servlet & JSP API
AssignedTo: dev@tomcat.apache.org
ReportedBy: mike@vorburger.ch
Classification: Unclassified
Tomcat (v7.0.21 at least) returns the absolute file path where a folder "would
have been" for servletContext.getRealPath("/someFolderThatDoesNotExist/").
Jetty (v7.3.0) returns null in such cases (so it only returns resources, or
folder, that are actually available in the directory where the expanded WAR
is); see also http://dev.eclipse.org/mhonarc/lists/jetty-dev/msg00773.html
The Servlet Spec doesn't clearly say either way - what Jetty does seems more
logical to me... and is also the assumption made e.g. in BIRT; for more
background see https://bugs.eclipse.org/bugs/show_bug.cgi?id=357315 &
http://mifosforge.jira.com/browse/MIFOS-5118.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 51799]
servletContext.getRealPath("/someFolderThatDoesNotExist/") should return null
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51799
--- Comment #1 from Mark Thomas <ma...@apache.org> 2011-09-21 12:16:09 UTC ---
My reading of the Servlet specification and Javadoc is that there is no
requirement for the path to exist, just for the container to map the virtual
path to a physical if such a mapping is possible.
I'll raise a bug against the Servlet specification to get this clarified but my
inclination is to resolve this as invalid.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 51799]
servletContext.getRealPath("/someFolderThatDoesNotExist/") should return null
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51799
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #5 from Mark Thomas <ma...@apache.org> 2011-09-23 06:42:01 UTC ---
The EG is in agreement (including the Jetty rep) that the current behaviour is
correct.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 51799]
servletContext.getRealPath("/someFolderThatDoesNotExist/") should return null
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51799
--- Comment #3 from Remy Maucherat <re...@apache.org> 2011-09-21 14:21:13 UTC ---
The behavior has never changed, has always been consistent, and nowhere in the
specification does it say the path needs to exist. Unlike for getResource,
where the behavior for a non existent resource is clearly defined as being
different. So why is there any doubt about this ?
If you didn't realize this could be used to create a file in the filesystem,
then it would still be nice to not assume by default that the specification
must be stupid because a user says so. And that, even if there wasn't any good
reason at all, the change would *again* break plenty of existing applications.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 51799]
servletContext.getRealPath("/someFolderThatDoesNotExist/") should return null
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51799
--- Comment #2 from Mark Thomas <ma...@apache.org> 2011-09-21 12:21:40 UTC ---
See http://java.net/jira/browse/SERVLET_SPEC-11
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 51799]
servletContext.getRealPath("/someFolderThatDoesNotExist/") should return null
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51799
--- Comment #4 from Mark Thomas <ma...@apache.org> 2011-09-21 16:56:19 UTC ---
Remy, I agree with you completely that Tomcat's behaviour is correct but having
read the spec quite carefully I couldn't find anything explicit that states
that the resource doesn't have to exist and there was enough ambiguity that I
can understand how someone may have reached a different conclusion. I just
think a few words of clarification in the spec wouldn't hurt. If you wanted to
add you views to SPEC-11 that would be great.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org