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
Using the Automatic Web Application Deployment model is quick and easy, but sometimes you might need to tune certain deployment properties (for example, you want to deploy with a context path that is not based on the file name, or you want to define a special database connection pool just for this web application). You can use a Jetty Deployable Descriptor XML File to accomplish such tuning.
Jetty supports deploying Web Applications via XML files which will build an instance of a ContextHandler that Jetty can then deploy.
In a default Jetty installation, Jetty scans its
$JETTY_HOME/webapps directory for context
deployment descriptor files. To deploy a web application using such a
file, simply place the file in that directory.
The deployment descriptor file itself is an xml file that
class. For a basic installation you probably need to set only two
the filesystem path to the web application file (or directory)
the context path to use for the web application
For example, here is a descriptor file that deploys the file
/opt/myapp/myapp.war to the context path
You can use the
Property elements in your descriptor file. For example,
if you set the system property
can rewrite the previous example as:
If you need to change the home path for your application, you can simply change the system property. This is useful if you frequently switch among multiple versions of an app.
If you look at the documentation for the
class, you notice that there are a lot more properties than just the two
mentioned above. Here are some examples that configure advanced options
with your descriptor file.
This first example tells Jetty not to expand the WAR file when deploying it. This can help make it clear that people should not be making changes to the temporary unpacked WAR because such changes do not persist, and therefore do not apply the next time the web application deploys.
The next example retrieves the JavaEE Servlet context and sets an
initialization parameter on it. You can also use the
setAttribute method to set a Servlet context attribute.
However, since the
web.xml for the web application
is processed after the deployment descriptor, the
web.xml values overwrite identically named attributes from
the deployment descriptor.
The following example sets a special
override descriptor. This descriptor is processed after the web
web.xml, so it may override
identically named attributes. This feature is useful if you want to add
parameters or additional Servlet mappings without breaking open a packed
The next example configures not only the web application context,
but also a database connection pool (see Datasource Examples that our application can then use.
web.xml does not include a reference to
this data source, you can use the override descriptor mechanism (the
previous example), to include it.
There are many other settings that you can change on a
for WebAppContext is a good source of information. Also see the
documentation on avoiding
zip file exceptions for a description of WebAppContext settings
that determine such things as whether or not the war is automatically
unpacked during deployment, or whether certain sections of a webapp are
copied to a temporary location.