Request Processing involves a sequence of steps that Tapestry performs when every HTTP request comes in. You don't need to know these steps to use Tapestry productively, but understanding

Request Processing

Understanding the request processing pipeline is very important, as it is one of the chief extension points for Tapestryhelpful if you want to understand Tapestry deeply.

Much of the early stages of processing are in the form of extensible pipelines.

...

All incoming requests originate with the TapestryFilter, which is a servlet filter configured inside the your application's web.xml.

The TapestryFilter is responsible for a number of startup and initialization functions.

When it receives a request, the TapestryFilter obtains the HttpServletRequestHandler service, and invokes its service() method.

From Tapestry 5.7.0 on, you can use TapestryFilter from org.apache.tapestry5.http instead of org.apache.tapestry5 if you want to use Tapestry's request processing framework (tapestry-http package) without the page framework (which is in tapestry-core).

HttpServletRequestHandler Pipeline

This pipeline performs initial processing of the request. It can be extended by contributing a HttpServletRequestFilter into the HttpServletRequestHandler service's configuration.'

Tapestry does not contribute any filters into this pipeline of its own.

The terminator for the pipeline does two things:

• It stores the request and response into the RequestGlobals service. This is a threaded per-thread scoped service that stores per-thread/per-request information.
• It wraps the request and response as a Request and Response, and passes them into the RequestHandler pipeline.
  Primarily, this exists to bridge from the Servlet API objects to the corresponding Tapestry objects. This is the basis for the planned portlet integration for Tapestry.

RequestHandler Pipeline

This pipeline is where most extensions related to requests take place. Request represents an abstraction on top of HttpServletRequest; this is necessary to support non-servlet applications, such as portlet applications. . (Primarily, this exists to bridge from the Servlet API objects to the corresponding Tapestry objects. This is to allow for a possible portlet integration for Tapestry.) Where other code and services within Tapestry require access to information in the request, such as query parameters, that information is obtained from the Request (or Response) objects.

The RequestHandler pipeline includes a number of built-in filters:

• CheckForUpdates is responsible for class and template reloading.
• Localization identifies the locale for the user.
• StaticFiles checks for URLs that are for static files (files that exist inside the web context) and aborts the request, so that the servlet container can handle the reuest request normally.
• ErrorFilter catches uncaught exceptions from the lower levels of Tapestry and presents the exception report page. This involves the RequestExceptionHandler service, which is responsible for initializing and rendering the core/ExceptionReport page.

The terminator for this pipeline stores the Request and the Response into RequestGlobals, then requests that the MasterDispatcher service figure out how to handle the request (if it is, indeed, a Tapestry request).

Master Dispatcher Service

The MasterDispatcher service is a chain-of-command, aggregating together (in a specific order), several Dispatcher objects. Each Dispatcher is built to recognize and process a particular kind of URL.

The dispatchers below are not present if you're using tapestry-http without tapestry-core.

RootPath

...

Dispatcher

The RootPath Dispatcher recognizes a request As discussed elsewhere, requests for the context root will instead be treated like render requests application root (i.e., "/") and handles this the same as a render request for the "startStart" page. Support for the Start page is kept for legacy purposes. Index pages are the correct approach.

Asset Dispatcher

Requests that being begin with "/assets/" are references to asset resources that are stored on the classpath, inside the Tapestry JARs (or perhaps inside the JAR for a component library). The contents of the file will be pumped down delivered to the client browser as a byte stream. This dispatcher also handles requests that are simply polling for a change to the file.

PageRender Dispatcher

Page render requests are requests to render a particular page. Such requests may include additional elements on the path, which will be treated as activation context (generally see ComponentEvent Dispatcher below). Generally speaking, the activation context is the primary key of some related entity object), allowing . This allows the page to reconstruct the state it will need to successfully render itself.

...

Page render URLs consist of the logical name of the page plus additional path elements for the activation context. The dispatcher here strips terms off of the path until it finds a known page name. Thus, "/mypage/27" would look first for a page whose name was "mypage/27", then look for a page name "mypage". Assuming the second search was successful, the page would be activated with the context "27". If no logical page name can be identified, control passes to the next dispatcher.

ComponentEvent Dispatcher

The component event ComponentEvent dispatcher is used to trigger events in components.

...

The response from a component action request is typically, but not universally, used to send a redirect to the client; the redirect URL is a page render URL to display the response to the event. This is detailed under page navigation Request Processing.

RequestGlobals Service

The RequestGlobals service has a life cycle of per-thread; this means that a separate instance exists for every thread, and therefore, for every request. The terminators of the two handler pipelines store the request/response pairs into the RequestGlobals service.

...

The Request service is a shadow of the RequestGlobals services' request property. That is, any methods invoked on this service are delegated to the request object stored inside the RequestGlobals.

Overview

The following diagram provides an overview of how the different pipelines, filters and dispatchers interact when processing an incoming request.

Image Added