Page History

 This page is intended to collect the reasons for and against the removal of this feature. The main purpose is to review use cases for using unpackWARs to ensure that a suitable alternative would be available if the feature was removed but all arguments for and against the feature are welcome.   

Background

Prior to Tomcat 8 unpackWARs=false did not result in the web application running entirely from the WAR. For performance reasons, any JARs in WEB-INF/lib were unpacked to the work directory and accessed from there. Tomcat 8 introduced a new resources implementation that did not perform this unpacking. This had a significant (e.g. 3x to 10x slower application start) performance impact - Bug 57251. One of the options suggested in the discussion on that bug was the removal of the unpackWARs feature.   

...

Simpler deployment while Tomcat is stopped

If unpackWARs=true and a WAR is updated while Tomcat is stopped, Tomcat will not realise that the unpacked directory structure is from an older version of the WAR and will continue to use it. The current work-arounds are:  

...

Security - make appBase read-only

...

Note that this discussions assumes a pre-existing application or Tomcat vulnerability that permits writing files into Tomcat's appBase.   

...

Actually read-only filesystem

If the filesystem is actually read-only (or effectively so, where the effective Tomcat user has no file-write rights whatsoever), then unpackWARs must be false in order to deploy. If all JSPs are pre-compiled and logs are not written to disk, Tomcat should be able to run on a read-only filesystem.   

...

Testing - configuration with getRealPath() returning null

...

When unpackWARs="false" the SevletContext.getRealPath() method always returns null. This configuration can be used to test that a web application is programmed correctly and can function without relying on getRealPath() method.   

...