All Tapestry applications make use of the ApplicationServlet class as their servlet; it is rarely necessary to create a subclass.
Example 4.1. Virtual Library Deployment Descriptor
<?xml version="1.0"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> <web-app> <distributable/> |
![]() | This indicates to the application server that the Tapestry application may be clustered. Most application servers ignore this element, but future servers may only distribute applications within a cluster if this element is present.
| ||||
![]() | The servlet name may be used when locating the application specification (though not in this example). | ||||
![]() | The servlet class is nearly always ApplicationServlet. There's rarely a need to create a subclass; Tapestry has many other hooks for extending the application. | ||||
![]() | The Virtual Library application stores its specification on the classpath, rather than under WEB-INF, so it is necessary to provide the complete path to the specification. Most applications can omit this <init-param>. | ||||
![]() | The servlet is mapped to /app within the context. The context itself has a path, determined by the application server, but typically /vlib. The client web browser will see the Tapestry application as http://host/vlib/app. Using /app as the URL is a common convention when creating Tapestry applications, but is not a requirement. |
On initialization, the Tapestry servlet will locate its application specification; a file that identifies details about the application, the pages and components within it, and any component libraries it uses. Tapestry provides a great deal of flexibility on where the specification is stored; trivial Tapestry applications can operate without an application specification.
Prior to release 3.0, application specifications had to be stored on the classpath. This is maintained for backwards compatibility. In modern applications, the specification is stored under WEB-INF. In fact, Tapestry performs a search to find the specification:
On the classpath, as defined by the org.apache.tapestry.application-specification configuration parameter.
As /WEB-INF/name/name.application. The name is the servlet name. This location is only used in the rare case of a single WAR containing multiple Tapestry applications.
As /WEB-INF/name.application. Again, name is the servlet name. This is the standard scenario.
If the application specification still can not be found, then an empty, "stand in" application specification is used.