What changes require a redeploy?
I noticed that in my exploded WAR file, if I make changes to a Facelet (similar to JSP) or stylesheet while Tomcat is running, I see the change when I navigate to that page in my browser. What changes are automatically picked up, and what requires a redeploy? Things include changes to the server's web.xml, server.xml, libraries, and the context's web.xml, faces-config.xml, Java classes, etc. Could somebody please describe what the mechanism going on here is, that allows for immediate updating in some cases but not others? Thanks. -- View this message in context: http://www.nabble.com/What-changes-require-a-redeploy--tf3764471.html#a10641404 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]
Re: What changes require a redeploy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lightbulb, lightbulb432 wrote: I noticed that in my exploded WAR file, if I make changes to a Facelet (similar to JSP) or stylesheet while Tomcat is running, I see the change when I navigate to that page in my browser. What changes are automatically picked up, and what requires a redeploy? JSPs (and probably related technologies) have their own ClassLoader and the manager within Tomcat (or the component that manages them) generally looks for changes, recompiles, and re-loads the individual page (or whatever) without a context reload. All other changes require a context (webapp) re-load. Basically, unless your particular technology supports automatic re-loading of the resource in question, you will have to re-load your webapp. Tomcat, if configured to do so, will automatically re-load the context if certain things change: WEB-INF/lib/*.jar, WEB-INF/classes/**/*.class, and WEB-INF/web.xml will trigger an automatic re-load of the context. There may be others as well (such as META-INF/context.xml). I believe that the only thing Tomcat can re-load without re-loading the entire context is JSPs. If you are using another technology on top of Tomcat (such as Facelets), it's up to that library to determine whether this capability is available. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGSzpV9CaO5/Lv0PARArnMAJ44GunwoN1EuaChr9R0fKpHC16JpACgr7/4 /gfu4GPTUUpcdYw0oN3sUqQ= =nhEc -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]
Re: What changes require a redeploy?
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]
Re: What changes require a redeploy?
On 5/16/07, lightbulb432 [EMAIL PROTECTED] wrote:
Do contexts that are deployed as exploded (as opposed to archived) WARs not
produce a work folder then?
They certainly do; in a standard install, it's under
$CATALINA_HOME/work/Catalina/{hostname}/{context}
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.
.. while it sounds like you're using some non-standard repackaged
version -- bummer :-)
Good luck,
--
Hassan Schroeder [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: What changes require a redeploy?
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]
RE: What changes require a redeploy?
From: lightbulb432 [mailto:[EMAIL PROTECTED] Subject: Re: What changes require a redeploy? Do contexts that are deployed as exploded (as opposed to archived) WARs not produce a work folder then? The work folder is used for several things besides unpacking WARs; see my previous message. I deploy with exploded WARs and don't see a work folder anywhere It's there someplace. Search for *_jsp.java and *_jsp.class files. as my folder structure (Tomcat home, Tomcat base, application files, etc) is all over my filesystem. As Hassan implied, you should throw away that repackaged junk and use a real Tomcat download. - 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]
RE: What changes require a redeploy?
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]
Re: What changes require a redeploy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, 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; Thanks for pointing this out. It occurred to me that this fact was self-evident, but the OP is asking about things like this. 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. Thanks for pointing this out as well: a WAR file is always exploded... the only question is where it will actually end up going. It looks like you can't avoid the work directory at all, since... The work directory is also used to hold translated and compiled JSPs and serialized sessions. ...these types of things may or may not exist in your WAR file, so use of the work directory is unpredictable. Tomcat then always creates that directory just in case? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGS2fX9CaO5/Lv0PARApUNAKCYtUKluqjcyGa5nFZYUg1vZupcMgCaAg96 3vTVrQF96BRpLi03MgoGS+o= =/4E0 -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]
Re: What changes require a redeploy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lightbulb, lightbulb432 wrote: 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? I would imagine that performance is the same: the only difference is the base directory from which files are loaded. Work versus appBase/appname should be identical. Maintenance is a judgment call: it is more straightforward to find your webapp's exploded WAR file in the webapps directory, or in some temporary directory whose location may not be fixed (say, across versions of Tomcat, or depending on a packaged version, etc.). I tend to think that expanding the WAR into the appBase directory makes more sense, myself. Also, I tend to serve static content using Apache httpd, and having a predictable directory where the files will definitely go is a plus (for me). I'm not sure why you would want to set unpackWARs=false. I'm guessing that static content served by Tomcat from your webapp will be served whether the WAR is expanded into a work directory or into appBase/appname, so I can't see any security benefits either way, either. The only thing I can think of is that Tomcat might not have write access to the appBase directory for some security reason. In that case, you'd /have/ to use a work directory since Tomcat couldn't actually expand the WAR file there. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGS2mj9CaO5/Lv0PARAjipAJoDfrZud2f9fM4qll20hQzo6QrBVACfXEbl +jdSuElWFLjnwNl1aqlXYnE= =4KTU -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]
RE: What changes require a redeploy?
From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: What changes require a redeploy? Tomcat then always creates that directory just in case? Yes, you can delete it and the next startup will recreate work and subdirectories for each Host and deployed webapp. - 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]
