Understanding Spring MVC: From Servlets to DispatcherServlet and Request Handling

1. The Former King – Servlet

Servlets were the original way to handle HTTP requests in Java, encapsulating request data in HttpServletRequest and response data in HttpServletResponse . Developers had to write much boiler‑plate code, but the model clarified request‑response flow.

2. Limitations of Plain Servlets

When applications grow, using a separate Servlet for each request becomes unwieldy, manual parameter extraction and validation are repetitive, URL mappings are static in web.xml , and business logic is tightly coupled to view rendering.

3. Spring MVC – Two‑Level Controller

Spring MVC introduces a front controller called DispatcherServlet (the "super servlet") and a secondary controller called a Handler (often implemented as a @Controller ). The DispatcherServlet receives all requests and delegates them to appropriate Handlers.

4. DispatcherServlet – Front Controller

The DispatcherServlet centralises request processing: it performs parameter binding, validation, URL matching, view resolution, and data rendering, acting as the orchestrator of the whole request lifecycle.

5. HandlerMapping – Request Mapping Expert

HandlerMapping determines which Handler should process a given URL. Common implementations include SimpleUrlHandlerMapping , ControllerClassNameHandlerMapping , BeanNameUrlHandlerMapping , and the annotation‑driven DefaultAnnotationHandlerMapping (using @RequestMapping ).

6. HandlerInterceptor – Intercepting Requests

Before a Handler executes, one or more HandlerInterceptors can inspect or block the request (similar to Servlet Filters but at the Handler level). If any interceptor returns false , the request is aborted.

7. Handler – Business Logic Execution

The Handler (or Controller) contains the actual business logic, invoking services and preparing data for the view.

8. HandlerExecutionChain – Bridging Handler and Interceptors

HandlerMapping returns a HandlerExecutionChain , which bundles the chosen Handler with its associated HandlerInterceptors, forming a chain that the DispatcherServlet executes sequentially.

9. ModelAndView – Decoupling Data and View

Handlers return a ModelAndView object that holds model data and the logical view name, separating business processing from view rendering.

10. ViewResolver – Finding the View

Based on the logical view name, a ViewResolver selects a concrete View implementation (e.g., JSP, FreeMarker, Velocity, JasperReports). Various resolvers such as BeanNameViewResolver , InternalResourceViewResolver , and FreeMarkerViewResolver are available.

11. View – Rendering the Response

The chosen View renders the model data into the final response (HTML, JSON, etc.) and returns it to the DispatcherServlet, which writes it back to the client.

Configuration Example

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" version="3.0">
    <servlet>
        <servlet-name>Spring MVC</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>classpath:Spring-servlet.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Spring MVC</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
</web-app>

The article concludes with a flow diagram summarising the entire Spring MVC request processing pipeline.