private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
This page contains content that we have migrated from Jetty 7 or Jetty 8 documentation into the correct format, but we have not yet audited it for technical accuracy in with Jetty 9. Be aware that examples or information contained on this page may be incorrect. Please check back soon as we continue improving the documentation, or submit corrections yourself to this page through Github. Thank you.
Table of Contents
pages about debugging configuration, troubleshooting warnings in the logs, etc
A Zip exception occurs when Jetty rereads a Jar or WAR file.
The JVM maintains a cache of zip file indexes, and does not support hot replacement of zip files. Thus if you redeploy a web application using the same WAR or Jar files, exceptions occur when Jetty rereads the jars. See Oracle Bug 4774421 for more information.
The remedy is to avoid hot replacing Jar or WAR files, which can be difficult if you are using the hot Context Provider. You can use the following techniques to reduce exposure to this issue:
Deploy unpacked classes in the
WEB-INF/classes
directory rather than as a Jar
file under WEB-INF/lib
.
Deploy all WAR and Jar files with a version number in their filename or path. If the code changes, a new version number applies, avoiding the cache problem.
Deploy a packed WAR file with the setExtractWAR option set to true. This causes the WAR to be extracted to a temporary directory and thus to a new location. This might not be sufficient if you want to hot-replace and reextract the WAR, so you might also need to use WebAppContext.setCopyWebInf(true), which (re)copies just the WEB-INF directory to a different location.
Deploy an unpacked WAR file with the setCopyWebDir option set to true. This causes the directory to be extracted to a new location.
Be aware that any of the techniques listed above that involve copying part or all of the webapp will probably not avoid the zip file problem if you are using a work directory (which avoids re-extraction on start/stop of a context or container).
If you have problems with Windows file-locking preventing static file editing (such as JSP or HTML), use the WebAppContext.setCopyWebDir(true) option.
See an error or something missing? Contribute to this documentation at Github!