Tobias Crefeld wrote:
> Am Mon, 12 Oct 2009 13:01:44 +0200
> schrieb Jesse Long <jpl@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
|