ports/75348: Tomcat port overwrites server.xml config file
Thomas Duffey
tduffey at homeboyz.org
Tue Dec 21 11:55:49 PST 2004
Hi All,
Brent Verner wrote:
>[2004-12-21 13:07] Manfred Riem said:
>| Why not use server.xml.sample for the original version?
>| That way one never has to worry ;) And it is the same
>| scheme as with rc scripts.
>
> Yes, except that server.xml and web.xml and other config
>files are _required_ for a working tomcat installation. I'm
>not opposed to the .sample approach, but I'm afraid that
>breaks the principle of least surprise (and this list
>would be fielding more bug reports because of tomcat not
>working after an upgrade). If we did this, we'd still have
>to juggle config files around to, with great certainty,
>leave the user with a working tomcat after an upgrade.
>
> There is likely no way we can have the right thing happen
>all the time, but I think the chosen solution should be the
>one that has the best chance of doing the right thing more
>often than any other.
>
>
Although this is not a solution to the overwriting problem, it is a
workaround that I typically use on all of my Tomcat servers to make it
easy to upgrade Tomcat within its minor releases without worrying about
trashing your files in <tomcat home>/conf. As a bonus, it lends itself
well to running Tomcat as a non-privileged user.
1) Install Tomcat through ports. Now you have Tomcat in
/usr/local/jakarta-tomcatXX
2) Create a new user on your system for your web application. Suppose
you want to run something called "foo." Create a "foo" user, and create
a "tomcat" directory in that user's home directory.
3) Copy the conf, logs, temp, webapps and work directories from Tomcat's
base distribution into the "foo" user's "tomcat" directory, e.g.
/home/foo/tomcat/conf
/home/foo/tomcat/logs
/home/foo/tomcat/temp
/home/foo/tomcat/webapps
/home/foo/tomcat/webapps/...
/home/foo/tomcat/work
4) Edit the files in /home/foo/tomcat/conf to your heart's content,
knowing that a port upgrade will never touch these files.
5) Create startup scripts in /home/foo/bin to start this instance of
Tomcat. Something like this works for startup:
#!/bin/sh
JAVA_HOME="/path/to/jdk" \
CATALINA_OPTS="-Xms32m -Xmx512m -Djava.awt.headless=true ..." \
CATALINA_BASE=`dirname $0` \
/usr/local/jakarta-tomcatXX/bin/startup.sh
and for shutdown:
#!/bin/sh
JAVA_HOME="/path/to/jdk" \
CATALINA_OPTS="-Xms32m -Xmx256m -Djava.awt.headless=true ..." \
CATALINA_BASE=`dirname $0` \
/usr/local/jakarta-tomcatXX/bin/shutdown.sh
Now you have your own set of configuration files, webapps, logs, etc.
and startup/shutdown routine that will run Tomcat under as the "foo"
user, utilizing most of the standard Tomcat distribution but giving you
the flexibility to make changes where they are most necessary.
Upgrading from Tomcat 4.1.x to 4.1.z should be as simple as running
portupgrade and restarting foo's instance. A major upgrade will
probably require changes to the foo instances configuration files, but
that should be expected. Yet another benefit is that you can easily
switch between different JDKs you have installed on your system just by
changing the foo user's startup and shutdown scripts.
Works great for me!
- Tom
More information about the freebsd-java
mailing list