Processing

El DispatcherServlet procesa las peticiones de la siguiente manera:

• Se busca el WebApplicationContext y se vincula (bind) a la petición como un atributo, para que el controlador (controller) y otros elementos del flujo puedan usarlo.

  Se vincula por defecto bajo la clave DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE.

• El resolutor de locale (locale resolver) se vincula a la petición para permitir que los elementos en el proceso puedan determinar qué idioma/localización usar cuando procesan la petición (por ejemplo, para renderizar la vista o preparar datos).

  Si no necesitas manejar idiomas o localización, puedes ignorar el locale resolver.

• El resolutor de tema (theme resolver) también se vincula a la petición para que elementos como las vistas puedan determinar qué tema usar (por ejemplo, para cambiar estilos visuales dinámicamente).

  Si no usas temas, no hace falta configurarlo.

• Si especificas un multipart file resolver, la petición se inspecciona para detectar si contiene partes multipart (por ejemplo, archivos subidos).

  Si encuentra multipartes, la request se envuelve en un MultipartHttpServletRequest para que los demás componentes puedan procesarla correctamente.

  (Ver: Multipart Resolver para más info sobre el manejo de archivos en formularios).

• Se busca un handler adecuado (normalmente, un controlador).

  Si se encuentra uno, se ejecuta su handler execution chain, que puede incluir preprocesadores, postprocesadores y el controller mismo, para preparar un modelo (model) que será usado para renderizar la vista.

  Alternativamente, si estás usando controladores con anotaciones, la respuesta puede ser renderizada directamente dentro del HandlerAdapter, sin necesidad de retornar una vista como tal.

• Si se retorna un modelo, se procede a renderizar la vista.

  Si no se retorna ningún modelo (por ejemplo, si un interceptor preprocesa la petición y ya genera una respuesta, como en casos de seguridad), entonces no se renderiza ninguna vista porque la petición ya fue resuelta.

• Los beans de tipo HandlerExceptionResolver declarados en el WebApplicationContext son usados para manejar excepciones que se lancen durante el procesamiento de la petición.

  Estos resolvers permiten personalizar cómo se manejan los errores. (Ver: Exceptions para más detalles).

• Para soporte de caché HTTP, los handlers pueden usar el método checkNotModified de WebRequest, junto con otras opciones adicionales si estás usando controladores con anotaciones. (Ver: HTTP Caching for Controllers).

Puede personalizar instancias individuales de DispatcherServlet añadiendo parámetros de inicialización de Servlet (elementos init-param) a la declaración de Servlet en el archivo web.xml. La siguiente tabla enumera los parámetros compatibles.

Parameter	Explanation
contextClass	Class that implements ConfigurableWebApplicationContext, to be instantiated and locally configured by this Servlet. By default, XmlWebApplicationContext is used.
contextConfigLocation	String that is passed to the context instance (specified by contextClass) to indicate where contexts can be found. The string consists potentially of multiple strings (using a comma as a delimiter) to support multiple contexts. In the 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.
throwExceptionIfNoHandlerFound	Whether to throw a NoHandlerFoundException when no handler was found for a request. The exception can then be caught with a HandlerExceptionResolver (for example, by using an @ExceptionHandler controller method) and handled as any others.
As of 6.1, this property is set to true and deprecated.
Note that, if default servlet handling is also configured, unresolved requests are always forwarded to the default servlet and a 404 is never raised.

Source: https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-servlet/sequence.html