tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Long <>
Subject Re: Persistent Storage for Webapps
Date Mon, 12 Oct 2009 16:57:43 GMT
Tobias Crefeld wrote:
> Am Mon, 12 Oct 2009 13:01:44 +0200
> schrieb Jesse Long <>:
>> 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/ 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/ 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message