The Deployment descriptor, which is a web.xml file, serves to tell a servlet container important details about a Java web application. Most commonly, it defines the servlets of the application and associates them with certain URL patterns, so that the servlet container knows which request should be passed to which servlet. Here is an example of a deployment descriptor, the one that would be typically be used in a Tapestry 4 application:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>Celebrity Collector</display-name>
<servlet>
<servlet-name>CelebrityCollector</servlet-name>
<servlet-class>
org.apache.tapestry.ApplicationServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>CelebrityCollector</servlet-name>
<url-pattern>/app</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
</web-app>

As you see, a Tapestry 4 application has just one servlet, named Celebrity Collector, and there is a Java class for it that is provided by the framework—all this is defined inside the<servlet> element. All requests addressed to the current application that start with /app, such as http://www.someserver.com/myapp/app, will be passed to this servlet, and then Tapestry will step in and do its job. This mapping is defined in the<servlet-mapping> element.

We can optionally define a session timeout—the amount of time in minutes after which the user's session will be invalidated if he or she will remain inactive. Also, a "welcome file" can be specified, which means a page that will be displayed if no specific page is requested by the user (for example, when navigating to http://www.someserver.com/myapp/).

In Tapestry 5, the deployment descriptor is somewhat unusual. This is what you will see if you look into the web.xml file of one of the applications created in this book:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<display-name>myapp Tapestry 5 Application</display-name>
<context-param>
<param-name>tapestry.app-package</param-name>
<param-value>org.example.myapp</param-value>
</context-param>
<filter>
<filter-name>app</filter-name>
<filter-class>
org.apache.tapestry.TapestryFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>app</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>

You can see that no servlets are defined in the Tapestry 5 deployment descriptor, and this is unusual. Instead, there is a filter, which is configured and associated with a URL pattern similarly to a servlet. Filters are normally used to do something before or after a servlet is invoked. In Tapestry 5, however, the whole framework looks to a servlet container as one complicated filter that intercepts all the requests and does with them whatever it thinks to be appropriate.

In the previous example, you can also see how certain values—in this case the package name of the application—can be provided in the deployment descriptor to be stored in application context—a special piece of memory where these values can be read later by the application.

This was a very brief overview of what a deployment descriptor is and what sort of information it can contain. If you are curious to know more, or if you need to know more to achieve the goals you are aiming for, please consult the Servlet Specification. It is perfectly readable, unlike some other specifications, and very useful.