-----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]
