Spring Web MVC

1.1. Introduction

Spring Web MVC is the original web framework built on the Servlet API and

included in the Spring Framework from the very beginning. The formal name "Spring

Web MVC" comes from the name of its source module spring-webmvc but it is more

commonly known as "Spring MVC".

Parallel to Spring Web MVC, Spring Framework 5.0 introduced a reactive stack,

delegate components. This model is flexible and supports diverse workflows.

The DispatcherServlet, as any Servlet, needs to be declared and mapped

according to the Servlet specification using Java configuration or in web.xml. In turn

the DispatcherServlet uses Spring configuration to discover the delegate components

it needs for request mapping, view resolution, exception handling, and more.

1.2.1. Context Hierarchy

DispatcherServlet expects a WebApplicationContext, an extension of a plain

ApplicationContext, for its own configuration. WebApplicationContext has a link to

the ServletContext and Servlet it is associated with. It is also bound to the

ServletContext such that applications can use static methods on RequestContextUtils

feature.

1.2.2. Special Bean Types

The DispatcherServlet delegates to special beans to process requests and render

the appropriate responses. By "special beans" we mean Spring-managed, Object

instances that implement WebFlux framework contracts. Those usually come with

built-in contracts but you can customize their properties, extend or replace them.

1.2.3. Web MVC Config

Applications can declare the infrastructure beans listed in Special Bean Types

that are required to process requests. The DispatcherServlet checks the

WebApplicationContext for each special bean. If there are no matching bean types, it

falls back on the default types listed in DispatcherServlet.properties.

In most cases the MVC Config is the best starting point. It declares the required

beans in either Java or XML, and provides a higher level configuration callback API

to customize it.

automatically mapped to the DispatcherServlet.

The isAsyncSupported protected method of AbstractDispatcherServletInitializer

provides a single place to enable async support on the DispatcherServlet and all filters

mapped to it. By default this flag is set to true.

Finally, if you need to further customize the DispatcherServlet itself, you can

override the createDispatcherServlet method.

1.2.5. Processing

Same in Spring WebFlux

The DispatcherServlet processes requests 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.

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

associated with the handler (preprocessors, postprocessors, and controllers) is

executed in order to prepare a model or rendering. Or alternatively for annotated

controllers, the response may be rendered (within the HandlerAdapter) instead of

returning a view.

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 HandlerExceptionResolver beans declared in the WebApplicationContext

resolvers allow customizing the logic to address exceptions. See Exceptions for more

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 individual DispatcherServlet instances by adding Servlet

initialization parameters ( init-param elements) to the Servlet declaration in the

web.xml file. See the following table for the list of supported parameters.

1.2.6. Interception

All HandlerMapping implementations supports handler interceptors that are

useful when you want to apply specific functionality to certain requests, for example,

checking for a principal. Interceptors must implement HandlerInterceptor from the

DispatcherServlet assumes the interceptor itself has taken care of requests (and, for

example, rendered an appropriate view) and does not continue executing the other

interceptors and the actual handler in the execution chain.

See Interceptors in the section on MVC configuration for examples of how to

configure interceptors. You can also register them directly via setters on individual

HandlerMapping implementations.

Note that postHandle is less useful with @ResponseBody and ResponseEntity

methods for which the response is written and committed within the HandlerAdapter

and before postHandle. That means its too late to make any changes to the response

such as adding an extra header. For such scenarios you can implement

ResponseBodyAdvice and either declare it as an Controller Advice bean or configure

it directly on RequestMappingHandlerAdapter.

1.2.7. Exceptions



@Controller

DispatcherServlet





HandlerExceptionResolver

!

"#$

%"#$





&



HandlerExceptionResolver

-./0

+ "1

2

3%**4*

5*1-6760 

8

)'

94:

;<=$*



*



$*

+9>

*$*

9>*8

*$*



$*

 UrlBasedViewResolver-(0,

 

5*1

?

RedirectView

#

redirect:/myapp/some/resource

