So you have multiple contexts on a host, each of which needs separate,
persistent storage?
If you don't want to keep track of a property files, you could write
a bean
with a method that takes a HttpRequest as a argument, and returns a
file
path based on the info in the request. You would have to dedicate a
directory on your server as the root for the persistence system.
Then build
subdirectories based on info available in the request object.
I could go on if you want, but basically I'm trying to say there is
more
than enough info in each HttpRequest to allow you build a flexible,
scalable
persistence system without having to resort to .properties files which
you'll then have to squirrel away somewhere and remember to update
each time
you change your Context name, etc. Just look at the javadocs for
HttpRequest. See especially getContextPath() and getLocalName().
Yes, these are good points about managing persistent data.
The OP's original issue with updating his WAR and deleting the data
directory - followed by trying to use temporary points out a
misconception about persistence that system administrators live to
solve. Persistent data has no business being in the webapps.
Webapps need to find the correct data. The system admin needs to
backup the data and perhaps restore it.
If Tomcat server A dies then does the service need to reappear on
Tomcat server B where is the data? This suggests that you should have
your data on a network mount point.
What if your webapps is insanely sucessful and you need to put your
server in the cloud? Where are you going to find your user's data? Did
you hear what happened to T-Mobile and the Sidekick - they just lost
most every client's contacts stored in their "cloud"
If you are stubborn and I've been myself with virtual host config on
the Tomcat 3.3 model, you will later spend dear effort programming
yourself out of the box. In my case we are nearly ready to go to
Tomcat 6 and a single Webapps completely in a single WAR able to run
multiple hosts (not SSL). Network storage and file-locking are
required, you can never assume you are the only one touching a file.
But now we are off topic, managing persistent data can take numerous
forms - see Apache Lucene, Hadoop, CouchDB, ... and then there are the
SQL...
Regards,
Dave
On Mon, Oct 12, 2009 at 12:57 PM, Jesse Long <j...@unknown.za.net>
wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
