- https://www.mulesoft.com/tcat/tomcat-configuration
- https://www.mulesoft.com/tcat/understanding-apache-tomcat
https://tomcat.apache.org/tomcat-8.5-doc/host-manager-howto.html https://tomcat.apache.org/tomcat-8.5-doc/config/host.html
https://tomcat.apache.org/tomcat-5.5-doc/config/host.html#Automatic Application Deployment
http://www.onjava.com/pub/a/onjava/2003/06/25/tomcat_tips.html
Removing the unpackWARs feature https://wiki.apache.org/tomcat/RemoveUnpackWARs
// unpackWARs="false" the
SevletContext.getRealPath();// method always returns nullhttps://docs.oracle.com/javaee/6/api/javax/servlet/ServletContext.html#getRealPath(java.lang.String)
getServletContext().getRealPath("/")
// returns '\' at the end when I run my project in Tomcat 7 whereas it is not
// working as such in Tomcat 8.
// For example,
// In Tomcat 7 it returns as "D:\Tomcat\webapps\project\"
// In Tomcat 8 it returns as "D:\Tomcat\webapps\project"
//At present the project is in production so, I am unable to change the code
//in every part(where i use getRealPath("/")). Is there a way/setting in
//tomcat level configuration to make it resolved.
//Additional information, Tomcat version : 8.0.14
tomcat implementation
https://bz.apache.org/bugzilla/show_bug.cgi?id=57556
// the servlet-2_3-fcs-docs for ServletContext.getRealPath():
// "This method returns null if the servlet 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)."
config.getServletContext().getRealPath("/" + storageLocation);
getServletContext().getResource("files");
// Read the javadoc for ServletContext.getResource:
//"Returns a URL to the resource that is mapped to a specified path. The
//path must begin with a "/" and is interpreted as relative to the current
//context root."
ServletContext#getRealPath()
// may return null in case that the cms.war is running without being unpacked.
// So, I think it's better to use a default storage directory instead in this
// case under the current working directory (e.g, "./repository_storage").
the question is
They will all get lost whenever the webapp get redeployed or even when the server get restarted with a cleanup. The simple reason is that the uploaded images are not contained in the to-be-deployed WAR file at all.
you
cannot rely on your web application being able to write in whatever directory
(if any) is its "current" directory (even supposing that this exists at all). This "current
directory" is whatever directory the JVM happens to be running in, which you
have no way to know in advance.
(Some day, your application may even be running inside a JVM and a Tomcat that
are entirely in some non-writeable kind of memory.)
have that application write something somewhere, and to
do this in a portable way, is to choose a place outside of the Tomcat directories, some
place that is guaranteed to be
created it that way (and you include this in your application's installation
instructions).
that location (on each system where it may be used), via some configurable
parameter that it can read.
And finally, there is another reason for not writing inside your web
application's
directory, even if this was possible : security.
If you allow Tomcat to write to your application directory, then possibly someone can take advantage of this via some
misconfiguration, and overwrite your code with malicious code that would do something else which you do not want to happen at all.
not be using /WEB-INF/classes/ to store static resources. Use /WEB-INF/resources/