Thanks for your thorough answer. What should be considered when making a decision between running with unpackWARs to true (running out of the exploded WAR in appBase) or false (forcing it to run out of the work directory)?
What are the tradeoffs or considerations, in terms of performance, maintenance, etc? In either case a work directory is still generated, right? - So what's the advantage to setting unpackWARs to true in a production environment? Caldarale, Charles R wrote: > >> From: Christopher Schultz [mailto:[EMAIL PROTECTED] >> Subject: Re: What changes require a redeploy? >> >> I think these resources are automatically "watched". You can certainly >> configure others. > > This is dependent on the reloadable attribute of the <Context> element; > the lib and classes directories are monitored only if the value is true, > which is not the default. Note that setting it to true results in > measurable overhead. > >> You could think about it like TC adding a WatchedResource for every >> class file it ever has to load. > > Again, only if reloadable is true for the <Context>. > >> I don't believe Tomcat does any significant static content caching in >> its default configuration. > > This is a function of the DefaultServlet. It does do some caching, but > this can be overridden by the browser. Look at the serveResource() > method in org/apache/catalina/servlets/DefaultServlet.java. > >> I'm sure you can configure it to do some caching > > I'm not aware of any config params for that, nor did a quick scan of the > code reveal any (doesn't mean they're not hiding somewhere). > >> The reason Tomcat "caches" class files (really it's >> Java that is keeping those in memory) is that re-loading >> a class is time consuming. > > The real reason is that classes have state, and so cannot be safely > changed without removing all references to both the classes and > instantiated objects. Also, some JVMs load .jar files into memory, and > won't notice that you've updated the one on disk. > >> The work folder basically contains just the exploded WAR file. > > Only when unpacking the WAR is inhibited by <Host> or <Context> > attributes or the .war is deployed in some location other than the > <Host>'s appBase directory; by default, a .war in appBase is unpacked > into the appBase directory. > >> You can (I think) avoid the work directory entirely by specifying >> unpackWARs="false" in your <Host> configuration. > > No, this forces use of the work directory; setting unpackWARs to true > allows the unpacking to occur in the appBase directory. Nothing is run > directly out of a .war file. > > The work directory is also used to hold translated and compiled JSPs and > serialized sessions. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the e-mail > and its attachments from all computers. > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/What-changes-require-a-redeploy--tf3764471.html#a10653201 Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
