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(). 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 > >
