Tobias Crefeld wrote:
Am Mon, 12 Oct 2009 13:01:44 +0200
schrieb Jesse Long <j...@unknown.za.net>:
In my webapp I need persistent storage. I am building my webapp as a
.war file, and copying it into $CATALINE_HOME/webapps/
Tomcat extracts $CATALINA_HOME/webapps/app.war to
$CATALINA_HOME/webapps/app/
The war file contains an empty directory /WEB-INF/data . During
operations, data files are created under /WEB-INF/data/
WEB-INF should contain only static files which shouldn't be accessible
by Webclients (directly), e.g. by /app/data/filename . So it seems to
be a bad place
Question: id /WEB-INF/ in the extracted directory the correct place
for persistent data storage? If not, where is?
AFAIK there is no general advise where to put dynamic, persistent data.
As system administrator I prefer solutions that give me the opportunity
to decide myself where to put dynamic data. There are a lot of reasons
for this: securing against disk space overflow, backup, priviledge
separation, etc.
Following this way you might create a "properties-"file outside the
Tomcat-hierarchy at a sensible place (e.g. /etc/app.properties) with
the paths your application should use.
Another way is to define a Tomcat-parameter during JVM-startup that will
contain the path to your data-directory. As this might not survive the
next update of Tomcat itself I don't like this kind of configuration
but some applications and classes are working this way.
My goal is to find a consistent way of creating persistent data
relative to the context. I dont want to have to configure context
parameters with data directory paths for each installation.
untested idea: If you have no control over the filesystem of the
target Tomcat you could create a mini-application named data.war that
you are deploying. Of course there is always the danger of accidentally
erasing the data by re-deploying this pseudo-application. And you will
have to find a way by valves, etc. to preserve this path from being
accessed by web-clients. Maybe it is enough if you leave out the
context-entry.
Thanks for your answers Tobias. Unfortunately we have a very real use
case for multiple instances on one host, with different data paths. So,
/etc/app.properties is not usable, but /etc/app-<context path derived
data>.properties might be but virtual hosting would break. No way to
identify unique host consistently.
Also, I could use a path name derived from the temp directory name, but
nothing says the temp directory name will be consistent. For now I will
reluctantly use context parameters.
Thanks,
Jesse
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
