Jetty Logo
Version: 9.4.5.v20170502
Contact the core Jetty developers at www.webtide.com

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 for sponsored feature development

Troubleshooting Slow Deployment

Remedies

After upgrading to a version of Jetty that supports Servlet Spec 3.0 or above, enabling some new modules, or introducing some new jars to your webapp, you notice that your deployment time is increased. This could be due to scanning for classes caused by a ServletContainerInitializer.

As documented in the section on Using Annotations, even if your webapp has set metadata-complete=true in web.xml, all jars within your webapp may still be scanned due to one or more ServletContainerInitializers that have a @HandlesTypes annotation listing the names of classes in which it is interested.

There are 3 ways to speed up deployment time:

Remedies

Limit Which ServletContainerInitializers to Execute

As documented in the section Excluding ServletContainerInitializers, you can provide a context attribute that defines a pattern of ServletContainerInitializer (SCI) class names to ignore. These SCIs will not be examined for @HandlesTypes and will not be executed. This is useful if you have included a 3rd party jar that has a SCI on which your code does not rely.

Limit Which Jars to Scan

As documented in the section Jars Scanned for Annotations, you can explicitly define which jars to include in the scanning process. This is helpful if you have a lot of jars in your webapp, and you know that they do not contain any classes referenced by an @HandlesTypes annotation on a ServletContainerInitializer that will be executed.

Limit Scanning to First Deployment Only (Quickstart)

The quickstart mechanism will do a normal deployment - obeying any limits on SCIs and jars to scan as documented here - the first time the webapp is deployed only. Subsequent deployments will re-use the information discovered during the first deployment. This is useful if you cannot limit the scan significantly by using any of the mechanisms described here, but you don’t want to incur the cost of scanning on every redeployment. The quickstart mechanism and how to use it is described here.

See an error or something missing? Contribute to this documentation at Github!(Generated: 2017-05-02)