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 you 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 the
DispatcherServlet
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 actual
Servlet
(it inherits from the
HttpServlet
base class), and as such is declared in
the web.xml
of your web application. You need to map
requests that you want the DispatcherServlet
to
handle, by using a URL mapping in the same web.xml
file. This is standard J2EE servlet configuration; the following example
shows such a DispatcherServlet
declaration and
mapping:
<web-app> <servlet> <servlet-name>example</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>example</servlet-name> <url-pattern>*.form</url-pattern> </servlet-mapping> </web-app>
In the preceding example, all requests ending with
.form
will be handled by the example
DispatcherServlet
. This is only the first step in
setting up Spring Web MVC. You
now need to configure the various beans used by the Spring Web MVC
framework (over and above the DispatcherServlet
itself).
As detailed in Section 3.13, “Additional Capabilities of the
ApplicationContext”,
ApplicationContext
instances in Spring can
be scoped. In the Web MVC framework, each
DispatcherServlet
has its own
WebApplicationContext
, which inherits all
the beans already defined in the root
WebApplicationContext
. These inherited
beans defined can be overridden in the servlet-specific scope, and
you 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 the
WEB-INF
directory of your 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 the web.xml
file):
<web-app> <servlet> <servlet-name>golfing</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>golfing</servlet-name> <url-pattern>/golfing/*</url-pattern> </servlet-mapping> </web-app>
With the above servlet configuration in place, you
will need to have a file called /WEB-INF/golfing-servlet.xml
in your application;
this file will contain all of your Spring Web MVC-specific components
(beans). You 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 plain ApplicationContext
that has some extra features necessary for web applications. It differs
from a normal ApplicationContext
in that it
is capable of resolving themes (see Section 15.7, “Using themes”),
and that it knows which servlet it is associated with (by having a link to
the ServletContext
). The
WebApplicationContext
is bound in the
ServletContext
, and by using static methods
on the RequestContextUtils
class you can always
look up the WebApplicationContext
if you
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. You can configure them in the
WebApplicationContext
, just as you
configure any other bean. However, for most beans, sensible defaults are
provided so you initially do not need to configure them. These
beans are described in the following table.
Table 15.1. 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 your 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 you set up a DispatcherServlet
, and a
request comes in for that specific
DispatcherServlet
, the
DispatcherServlet
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 you do not need locale resolving, you do not need it.
The theme resolver is bound to the request to let elements such as views determine which theme to use. If you do not use themes, you can ignore it.
If you 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. (See Section 15.8.2, “Using the
MultipartResolver” for further information about
multipart handling).
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.
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 you to define custom behaviors to address
exceptions.
The Spring DispatcherServlet
also supports
the return of the last-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 the
LastModified
interface. If so, the value of the long
getLastModified(request)
method of the
LastModified
interface is returned to the
client.
You can customize Spring's DispatcherServlet
by adding context parameters in the web.xml
file or
servlet initialization parameters. See the following table.
Table 15.2. 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 . |