Hi, One great way to approach production setups for Tomcat is one webapp per Tomcat instance. Restarts are then quick and easy, and no matter what this one webapp does (OutOfMemoryErrors, malicious code, etc.) it can't affect others you have running around because they're in a different JVM. The ease of setting up Tomcat standalone makes this not just feasible, but probably recommended over a many webapps per Tomcat instance setup.
Yoav Shapira http://www.yoavshapira.com >-----Original Message----- >From: Steven J.Owens [mailto:[EMAIL PROTECTED] >Sent: Saturday, November 06, 2004 3:27 AM >To: Tomcat Users List; [EMAIL PROTECTED] >Subject: Re: Configuration Management, JSP Recompiles, War Files > >On Sat, Nov 06, 2004 at 03:20:46AM -0500, Steven J. Owens wrote: >> On Mon, Oct 25, 2004 at 09:15:41AM -0400, Shapira, Yoav wrote: >> > > If I understand correctly, WAR file is just a glorified JAR file, >> > >which in turn is just a glorified tar file. So unless you're >> > >unjarring it, editing the config file and rejarring it, you can't >> > >really muck with the config settings inside it. How/where do people >> > >normally keep the configuration variables for the webapp? >> > >> > You might want to read up the Servlet Spec's section on resource-ref >and >> > env-entry refs. These provide a way for you to keep one WAR and edit >> > server.xml (or another server-specific, outside-your-WAR configuration >> > file) to modify configuration information. Your understanding above is >> > incomplete. >> >> So the standard practice is to put all of your configuration >> variables in server.xml and reboot the server if you need to change >> the configuration? > > Ah, your further comments in "RE: discussion on webapp reload in >production" indicates that restarting tomcat for changes is indeed >standard practice. Okay. > > Is there a HOWTO or tutorial anywhere on running an ASP style >setup (er, that's application service provider, not the other ASP) >with multiple apps, using tomcat? More of a "standard practices" sort >of thing, though how-to/tutorials for specific aspects would also be >cool. > >-- >Steven J. Owens >[EMAIL PROTECTED] > >"I'm going to make broad, sweeping generalizations and strong, > declarative statements, because otherwise I'll be here all night and > this document will be four times longer and much less fun to read. > Take it all with a grain of salt." - http://darksleep.com/notablog > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
