Re: Surprising auto-(un)deploy behavior
On Tue, Mar 31, 2009 at 10:56 AM, Rainer Frey (Inxmail GmbH) wrote: > > Then, is this intended behavior, or a bug? > > Rainer > Making a long story short: It's expected behaviour. >From the Tomcat 6 documentation (http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html): === [ snip ] Deployment on Tomcat startup If you are not interested in using the Tomcat Manager, or TCD, then you'll need to deploy your web applications statically to Tomcat, followed by a Tomcat startup. The location you deploy web applications to for this type of deployment is called the appBase which is specified per Host. You either copy a so-called exploded web application, i.e non-compressed, to this location, or a compressed web application resource .WAR file. The web applications present in the location specified by the Host's (default Host is "localhost") appBase attribute (default appBase is "$CATALINA_BASE/webapps") will be deployed on Tomcat startup only if the Host's deployOnStartup attribute is "true". The following deployment sequence will occur on Tomcat startup in that case: 1. Any Context Descriptors will be deployed first. 2. Exploded web applications not referenced by any Context Descriptor will then be deployed. If they have an associated .WAR file in the appBase and it is newer than the exploded web application, the exploded directory will be removed and the webapp will be redeployed from the .WAR 3. .WAR files will be deployed Note again that for each deployed web application, a Context Descriptor will be created unless one exists already. === [ snap ] Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 @ http://pgp.mit.edu:11371/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Surprising auto-(un)deploy behavior
On Tuesday 31 March 2009 09:42:58 Mark Thomas wrote: > Rainer Frey (Inxmail GmbH) wrote: > > In Tomcat 6.0 deployment works the same, but when I delete the war file, > > the application is undeployed and the expanded directory is deleted. Is > > this change documented somewhere, > > Doesn't look like it Then, is this intended behavior, or a bug? Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Surprising auto-(un)deploy behavior
tc 6 will definately use the latest deployment-descriptor - tested here with tc 6 on debian. however,if you delete the war, the spp will be undeployed rgds gregor Am 31.03.2009 um 09:42 schrieb Mark Thomas : Rainer Frey (Inxmail GmbH) wrote: In Tomcat 6.0 deployment works the same, but when I delete the war file, the application is undeployed and the expanded directory is deleted. Is this change documented somewhere, Doesn't look like it and is there a way to get the old behavior with tomcat 6.0? not unless you patch the source code. Also I think that in Tomcat 5, it was *necessary* to delete the war file to be able to edit the web.xml ofthe deployed application, otherwise it was overwritten from the war file at least at the next server start. What will Tomcat 6 do on startup in this case (a .war file *and* an expanded directory of the same webapp exist, with a newer web.xml in the expanded directory? I believe it will use the one in the expanded directory. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Surprising auto-(un)deploy behavior
Rainer Frey (Inxmail GmbH) wrote: > In Tomcat 6.0 deployment works the same, but when I delete the war file, the > application is undeployed and the expanded directory is deleted. Is this > change documented somewhere, Doesn't look like it > and is there a way to get the old behavior with > tomcat 6.0? not unless you patch the source code. > Also I think that in Tomcat 5, it was *necessary* to delete the war file to > be > able to edit the web.xml ofthe deployed application, otherwise it was > overwritten from the war file at least at the next server start. What will > Tomcat 6 do on startup in this case (a .war file *and* an expanded directory > of the same webapp exist, with a newer web.xml in the expanded directory? I believe it will use the one in the expanded directory. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Surprising auto-(un)deploy behavior
Hi, I just noticed a surprising behavior change between Tomcat 5.0 and Tomcat 6.0.18 regarding auto-undeployment of war files. I use both versions in default configuration, which means autoDeploy and unpackWARs are both true. (I don't think this matters much, but I tried this with Mac OS X and Java 5 as well as Linux and Java 6). In Tomcat 5.0, I copy the war file to the webapps directory, it is unpacked and deployed. Then I can delete the war file, and the web application runs and will be deployed on next start from the unpacked directory. In Tomcat 6.0 deployment works the same, but when I delete the war file, the application is undeployed and the expanded directory is deleted. Is this change documented somewhere, and is there a way to get the old behavior with tomcat 6.0? Also I think that in Tomcat 5, it was *necessary* to delete the war file to be able to edit the web.xml ofthe deployed application, otherwise it was overwritten from the war file at least at the next server start. What will Tomcat 6 do on startup in this case (a .war file *and* an expanded directory of the same webapp exist, with a newer web.xml in the expanded directory? My question regards development, so there is no need to convince me that autodeployment should not be used in production :-) Regards Rainer Frey - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org