THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Div |
|---|
Request Processing
| Wiki Markup | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
| |background=#eee}
{contentbylabel:title=Related Articles|showLabels=false|showSpace=false|space=@self|labels=request-processing}
{float}
| ||||||||
|
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 the request processing pipeline is helpful if you want to understand Tapestry deeplyUnderstanding the request processing pipeline is very important, as it is one of the chief extension points for Tapestry.
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.
...
- It stores the request and response into the RequestGlobals service. This is a 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.
RequestHandler Pipeline
This pipeline is where most extensions related to requests take place. Request represents an abstraction on top of HttpServletRequest. (Primarily, this exists to bridge from the Servlet API objects to the corresponding Tapestry objects. This is the basis for the planned 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 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).
...
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 for the application root (i.e., "/") and handles this the same as a render request for the "Start" page. Support for the Start page is kept for legacy purposes. Index pages are the correct approach.
...
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 following diagram provides an overview of how the different pipelines, filters and dispatchers interact when processing an incoming request.
| Scrollbar |
|---|