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