Thanks again for your thorough answer. Do contexts that are deployed as exploded (as opposed to archived) WARs not produce a work folder then? I deploy with exploded WARs and don't see a work folder anywhere, but I'm not sure whether that's how it's supposed to be - it could be somewhere but I just don't know where to find it, as my folder structure (Tomcat home, Tomcat base, application files, etc) is all over my filesystem.
Christopher Schultz-2 wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lightbulb, > > lightbulb432 wrote: >> When you mention the configuration to automatically reload the context, >> do >> you mean <WatchedResource>? >> >> If you set reloadable to true in the context configuration, that should >> take >> care of WEB-INF/lib and WEB-INF/classes, and they don't need to be >> specified >> in WatchedResource - is this correct? > > I think these resources are automatically "watched". You can certainly > configure others. > > The default context.xml file (at least, I /think/ it's the default) > found in $TOMCAT_HOME/conf/context.xml in my TC 5.5.23 specifies > WEB-INF/web.xml file as a watched resource, but does not mention the lib > or classes directories. > > Let me amend my earlier statement about TC's reloading of the context > when a class changes: TC will only trigger a context reload when a class > that has /already been loaded/ is changed. I believe that if you replace > an as-yet-unused class with a newer version, TC does nothing. > > You could think about it like TC adding a WatchedResource for every > class file it ever has to load. > > Note that this is completely the opposite of what you were originally > asking about: re-loading a specific resource without re-loading the > entire context (a la JSP). > >> Also, for static content like stylesheets that are within the WAR, a >> change >> to the stylesheet was immediately viewable in the browser - I found that >> surprising. Does Tomcat not do something like caching its static content >> and >> resources so that even if you change a file, that change isn't >> represented >> in the "work" folder? > > I don't believe Tomcat does any significant static content caching in > its default configuration. I'm sure you can configure it to do some > caching, though I'm not sure how useful that is. Reading bytes off the > disk is pretty fast. 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. Same thing with JSPs... compilation is a time-consuming > process, and so re-loading a JSP for every request would be silly. > > Changes to JSP source files typically trigger a re-load of that > particular JSP /only/. This is mainly a benefit to developers so that a > .jsp file change doesn't require a re-load of the entire context. > Context loading and configuration is time-consuming and should be > avoided in production whenever possible. > >> (I thought the concept of a work folder was essentially a cache... - if >> not, >> what is its purpose?) > > The work folder basically contains just the exploded WAR file. A WAR > file is compressed using ZIP-style compression. Reading things out of a > WAR file is time-consuming since the file must be opened, decompressed > (to a certain extent), the TOC needs to be read, the target data > located, then loaded and decompressed, etc. It's much faster to rely on > the filesystem to locate files by path and then serve the bytes directly. > > You can (I think) avoid the work directory entirely by specifying > unpackWARs="false" in your <Host> configuration. I think this will serve > only to slow down your webapp (but save some disk space, I suppose). > > - -chris > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGS0s19CaO5/Lv0PARAq2iAJ0R+79ChlAcz4IH76VqKvTvG57gBQCfYNxa > 99rxk/iAN4TsCIm7RLTpIpQ= > =QR8a > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > 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#a10652074 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]
