DispactcherServlet#
What Is The DispactcherServlet?#
- Spring's web MVC framework is, like many other web MVC frameworks, request-driven, designed around a central servlet that dispatches requests to controllers and offers other functionality that facilitates the development of web applications. Spring's
DispatcherServlet
however, does more than just that. It is completely integrated with the Spring IoC container and as such allows us to use every other feature that Spring has. - The request processing workflow of the Spring Web MVC
DispatcherServlet
is illustrated in the following diagram. The pattern-savvy reader will recognize that theDispatcherServlet
is an expression of the “Front Controller” design pattern (this is a pattern that Spring Web MVC shares with many other leading web frameworks).
- The
DispatcherServlet
is an actualServlet
(it inherits from theHttpServlet
base class), and as such is declared in theweb.xml
of our web application. We need to map requests that we want theDispatcherServlet
to handle, by using a URL mapping in the sameweb.xml
file. This is standard J2EE servlet configuration; the following example shows such aDispatcherServlet
declaration and mapping.
web.xml | |
---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
|
- In the preceding example, all requests will be handled by the
dispatcher
DispatcherServlet. This is only the first step in setting up Spring Web MVC. We now need to configure the various beans used by the Spring Web MVC framework (over and above theDispatcherServlet
itself.
DispactcherServlet And ApplicationContext#
ApplicationContext
instances in Spring can be scoped. In the Web MVC framework, eachDispatcherServlet
has its ownWebApplicationContext
, which inherits all the beans already defined in the rootWebApplicationContext
. These inherited beans defined can be overridden in the servlet-specific scope, and we can define new scope-specific beans local to a given servlet instance.
- Upon initialization of a
DispatcherServlet
, the framework looks for a file named[servlet-name]-servlet.xml
in theWEB-INF
directory of our web application and create the beans defined there, overriding the definitions of any beans defined with the same name in the global scope. - Consider the following
DispatcherServlet
servlet configuration (in theweb.xml
file).
web.xml | |
---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
- With the above servlet configuration in place, we will need to have a file called
/WEB-INF/sample/*.xml
in out application; this file will contain all of our Spring Web MVC-specific components (beans). We can change the exact location of this configuration file through a servlet initialization parameter (see below for details). - The
WebApplicationContext
is an extension of the plainApplicationContext
that has some extra features necessary for web applications. It differs from a normalApplicationContext
in that it is capable of resolving themes, and that it knows which servlet it is associated with (by having a link to theServletContext
). TheWebApplicationContext
is bound in theServletContext
, and by using static methods on theRequestContextUtils
class we can always look up theWebApplicationContext
if we need access to it. -
The Spring
DispatcherServlet
uses special beans to process requests and render the appropriate views. These beans are part of Spring Framework. We can configure them in theWebApplicationContext
, just as we configure any other bean. However, for most beans, sensible defaults are provided so we initially do not need to configure them. These beans are described in the following table. -
Special beans in the
WebApplicationContext
:
Bean type | Explanation |
---|---|
controllers | Form the C part of the MVC. |
handler mappings | Handle the execution of a list of pre-processors and post-processors and controllers that will be executed if they match certain criteria (for example, a matching URL specified with the controller). |
view resolvers | Resolves view names to views. |
locale resolver | A locale resolver is a component capable of resolving the locale a client is using, in order to be able to offer internationalized views |
Theme resolver | A theme resolver is capable of resolving themes our web application can use, for example, to offer personalized layouts |
multipart file resolver | Contains functionality to process file uploads from HTML forms. |
handler exception resolvers | Contains functionality to map exceptions to views or implement other more complex exception handling code. |
-
After we set up a
DispatcherServlet
, and a request comes in for that specificDispatcherServlet
, theDispatcherServlet
starts processing the request as follows:- The
WebApplicationContext
is searched for and bound in the request as an attribute that the controller and other elements in the process can use. It is bound by default under the key DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE. - The locale resolver is bound to the request to enable elements in the process to resolve the locale to use when processing the request (rendering the view, preparing data, and so on). If we do not need locale resolving, we do not need it.
- The theme resolver is bound to the request to let elements such as views determine which theme to use. If we do not use themes, we can ignore it.
- If we specify a multipart file resolver, the request is inspected for multiparts; if multiparts are found, the request is wrapped in a
MultipartHttpServletRequest
for further processing by other elements in the process. - An appropriate handler is searched for. If a handler is found, the execution chain associated with the handler (preprocessors, postprocessors, and controllers) is executed in order to prepare a model or rendering.
- If a model is returned, the view is rendered. If no model is returned, (may be due to a preprocessor or postprocessor intercepting the request, perhaps for security reasons), no view is rendered, because the request could already have been fulfilled.
- The
-
Handler exception resolvers that are declared in the
WebApplicationContext
pick up exceptions that are thrown during processing of the request. Using these exception resolvers allows us to define custom behaviors to address exceptions. - The Spring
DispatcherServlet
also supports the return of thelast-modification-date
, as specified by the Servlet API. The process of determining the last modification date for a specific request is straightforward:- The
DispatcherServlet
looks up an appropriate handler mapping and tests whether the handler that is found implements theLastModified
interface. If so, the value of thelong getLastModified(request)
method of theLastModified
interface is returned to the client.
- The
- We can customize Spring's
DispatcherServlet
by adding context parameters in theweb.xml
file or servlet initialization parameters. See the following table. DispatcherServlet
initialization parameters:
Parameter | Explanation |
---|---|
contextClass | Class that implements WebApplicationContext, which instantiates the context used by this servlet. By default, the XmlWebApplicationContext is used. |
contextConfigLocation | String that is passed to the context instance (specified by contextClass) to indicate where context(s) can be found. The string consists potentially of multiple strings (using a comma as a delimiter) to support multiple contexts. In case of multiple context locations with beans that are defined twice, the latest location takes precedence. |
namespace | Namespace of the WebApplicationContext. Defaults to [servlet-name]-servlet . |