https://bz.apache.org/bugzilla/show_bug.cgi?id=57736
--- Comment #4 from Frank Holler <frank.hol...@gmx.de> --- (In reply to Mark Thomas from comment #3) > (In reply to Frank Holler from comment #2) > > To use unpackWars="true" is a problem for us. > > Why? > > > So i digged a little deeper into the problem. > > I found out that Tomcat 7 and Tomcat 8 both extract classes and libs from > > WEB-INF to CATALINA_BASE/work/[app]/, even if unpackWars="false" is set. > > That is not correct. Tomcat 8 does not extract JARs or classes to the work > directory under any circumstances. > > One of the options considered to address the performance problems is to > restore the extraction of the JARs to the work directory but that creates > complexity in an area where we have been trying to reduce it. This is still > an option of last resort but my preference - where possible - is to address > the reasons why people can't use unpackWARs="true". You're rigt, my fault. i did not clean up the work directory after changing form unpackWars="true" to "false". So the remaining files was leftover from the last restart. The reason why we don't use unpackWars="true" is, that the unpacked directory won't get updated, if the war changes. For security reasons we (and our customers) don't deploy the "manager" or any other webapp, only our war. So the deployment process with unpackWars="false" is: 1.) drop the new war into webapps 2.) restart tomcat With unpackWars="true" and without using "manager"-app the steps to update would be: 1.) stop tomcat 2.) delete the unpacked folder => otherwise it won't work!!! 3.) drop the new war into webapps 4.) start tomcat again To check, if this behavior changed with tomcat 8 we did the following: Our webapp version 2.6.6 is deployed with unpackwars="true", the unpacked folder exists. Afterwards we replaced the WAR with version 2.6.7 and restart tomcat. As any version before, the unpacked directory wasn't updated, so the version 2.6.6 is started again, the new war with version 2.6.7 is ignored. After this problem occured often, we told our customers to set unpackWars="false", so our customers (and our support of course) has less problems when delvierung updates of our app. So perhaps you understand, why we won't like to tell our customers to change unpackWars back when updating to tomcat 8. I understand, that a revert of the changes isn't easy, but for my opinion, unpackWars="false" isn't usable with tomcat 8 any more without refactoring many of our logic to bypass the new loader behavior. The problem is, that we don't know, which of the used libs also have a problem (like com.mycila.xmltool), so we would be happy, if the behavior of tomcat 8 keeps compatible tomcat 7. Kind regards, Frank -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
