RE: unpackWARs Pros and Cons
We have encountered issues with deploying unpacked war files on Windows platforms: when redeploying webapps tomcat fails to clear out the unpacked directory because windows locks some jar files. There is a antiResourceLocking workaround but we decided to work with packed war files in the end -Original Message- From: Morris Jones [mailto:[EMAIL PROTECTED] Sent: 04 March 2007 01:35 To: Tomcat Users List Subject: Re: unpackWARs Pros and Cons Jim Goodspeed wrote: Are there any pros and cons running unpackWARs one way or another? It seems like keeping unpackWARs=false might be a little cleaner (not having to remove expanded directories when deploying a new war file), but I wasn't sure if there were any performance hits associated with running this set to false. I've been running with packed WARs for a while, and just ran into an issue with Spring's log4jContextListener. It demands that the war be unpacked so it can reference the application root as an absolute pathname. Tsk! I agree that leaving them packed is neater, and I like not having to worry about stale files in an exploded app directory, but I'm careful to delete the exploded directory most of the time anyway. Having them unpacked should have a slight performance advantage because the files don't have to be searched and unpacked from the WAR when they're referenced. Best regards, Mojo -- Morris Jones Monrovia, CA http://www.whiteoaks.com Old Town Astronomers: http://www.otastro.org - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [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: unpackWARs Pros and Cons
Rachel Wilson wrote: We have encountered issues with deploying unpacked war files on Windows platforms: when redeploying webapps tomcat fails to clear out the unpacked directory because windows locks some jar files. There is a antiResourceLocking workaround but we decided to work with packed war files in the end Tomcat unpacks them anyway - to the 'work' directory. But yes, this solves locking problem. -- Mikolaj Rydzewski [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
unpackWARs Pros and Cons
Are there any pros and cons running unpackWARs one way or another? It seems like keeping unpackWARs=false might be a little cleaner (not having to remove expanded directories when deploying a new war file), but I wasn't sure if there were any performance hits associated with running this set to false.
Re: unpackWARs Pros and Cons
Jim Goodspeed wrote: Are there any pros and cons running unpackWARs one way or another? It seems like keeping unpackWARs=false might be a little cleaner (not having to remove expanded directories when deploying a new war file), but I wasn't sure if there were any performance hits associated with running this set to false. I've been running with packed WARs for a while, and just ran into an issue with Spring's log4jContextListener. It demands that the war be unpacked so it can reference the application root as an absolute pathname. Tsk! I agree that leaving them packed is neater, and I like not having to worry about stale files in an exploded app directory, but I'm careful to delete the exploded directory most of the time anyway. Having them unpacked should have a slight performance advantage because the files don't have to be searched and unpacked from the WAR when they're referenced. Best regards, Mojo -- Morris Jones Monrovia, CA http://www.whiteoaks.com Old Town Astronomers: http://www.otastro.org - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
