https://bz.apache.org/bugzilla/show_bug.cgi?id=57736
--- Comment #5 from Mark Thomas <ma...@apache.org> --- (In reply to Frank Holler from comment #4) > 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 You must have also set autoDeploy="false" otherwise dropping an updated WAR into a running Tomcat instance would trigger a redploy. > 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 Not the case as of Tomcat 8.0.21. On restart, Tomcat will now detect the updated WAR, delete the expanded directory and expand the updated WAR (assuming deployOnStartup="true"). > 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. Tomcat's general policy for adding workarounds for bugs in other projects is that we won't do it. Fixing the issue at the source means the fix is more widely available and we have more time to spend on Tomcat bugs and new feature requests. We do make occasional exceptions - usually when the bug is likely to affect a large proportion of the Tomcat user based and the 3rd party vendor has indicated that they have no intention of fixing the bug. The new ability to detect an updated WAR while Tomcat has stopped looks to be sufficient to remove the need for your application to run with unpackWARs="false". The behaviour of javax.crypto with an unpacked WAR is a concern although we don't see as much bouncy castle usage as we used to. The issue with com.mycila.xmltool falls into the category that we'd expect the vendor to fix. As per the discussion on bug 57251 and as stated above, the preference remains to fix issues people have with unpackWARs="true". I haven't seen anything in this issue that explains why - as of 8.0.21 - running with unpackWARs="true" is not a viable option for you. -- 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
