From owner-freebsd-java@FreeBSD.ORG Tue Dec 21 19:55:49 2004 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCF7616A4CE for ; Tue, 21 Dec 2004 19:55:49 +0000 (GMT) Received: from morla.lan.homeboyz.com (morla.lan.homeboyz.com [38.119.239.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D9AF43D55 for ; Tue, 21 Dec 2004 19:55:49 +0000 (GMT) (envelope-from tduffey@homeboyz.org) Received: (qmail 93560 invoked from network); 21 Dec 2004 19:55:48 -0000 Received: from hbi-int87.lan.homeboyz.com (HELO ?192.168.1.87?) (tduffey@192.168.1.87) by morla.lan.homeboyz.com with AES256-SHA encrypted SMTP; 21 Dec 2004 19:55:48 -0000 Message-ID: <41C87FC4.4070803@homeboyz.org> Date: Tue, 21 Dec 2004 13:55:48 -0600 From: Thomas Duffey User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: freebsd-java@freebsd.org References: <200412211740.iBLHeUcw090127@freefall.freebsd.org> <20041221184340.GA14170@rcfile.org> <37919c31041221110775dc0396@mail.gmail.com> <20041221193221.GA14792@rcfile.org> In-Reply-To: <20041221193221.GA14792@rcfile.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ports/75348: Tomcat port overwrites server.xml config file X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2004 19:55:49 -0000 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 /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