Am Mon, 12 Oct 2009 18:57:43 +0200 schrieb Jesse Long <j...@unknown.za.net>:
> 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 > data>to > identify unique host consistently. It depends on how you implement virtual hosting. I have no experience with Tomcats virtual hosting but a Tomcat-application can always can request the hostname from the URI and use it to build a path name. We are using this hostname to give users via VPN other privileges than users via public internet. Not really secure but within our business it's enough. We're using Apache2-vhosts and run one Tomcat (in its own JVM) per vhost. This wastes RAM but avoids that a crash|deadlock|overload|whatever in one vhost affects the other vhosts seriously. In our scenario we have one "home"-directory per vhost (e.g. /srv/vhost1) where we install Tomcat (mostly by symbolic links to unpacked Tomcats-archives) incl. startup/shutdown-scripts, cronjobs, logs, Apache2-document-root, Tomcat-ROOT and persistent data for import/export. Tomcat's webapps-concept is only used to deploy some standard applications like Lambda probe, Webservice or j4p. This "vhost-home" also contains some *.properties-files with parameters, e.g. for database-access (we don't use JNDI due to historic reasons), paths for import/export, etc. If your using only one Tomcat with several name-based vhosts it probably will be enough if you read hostname from URI and use this information to construct the path to a tree with /srv/vhost1, /srv/vhost2, etc. as data directories. Gruß, Tobias. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
