What is the DispatcherServlet in Spring MVC, and what design pattern does it implement?
answer
- Single entry point = Front Controller
- It's a real Servlet (extends FrameworkServlet)
- Delegates to HandlerMapping/Adapter
- Boot maps it to '/'
- Stateless, one instance for all requests
basics
~10 sDispatcherServlet is Spring MVC's single entry point for HTTP requests. It implements the Front Controller pattern: one servlet receives every request and delegates to the right handler (controller), then renders the response.
solid answer
~40 sDispatcherServlet is a Java Servlet that acts as Spring MVC's Front Controller — a single central entry point that all matching HTTP requests pass through. Instead of many servlets, one DispatcherServlet receives the request, then delegates: it asks a HandlerMapping which controller handles the URL, invokes it via a HandlerAdapter, and turns the result into a response (via a view or message converter). This centralizes cross-cutting concerns like locale, theme, multipart parsing, and exception handling in one place. In Spring Boot it's auto-registered and mapped to '/' by default. The pattern's value is a single, consistent request-processing pipeline that all requests share, keeping controllers free of infrastructure code.
code
java · 15 lines// You rarely write this — Spring Boot does it. Manual (non-Boot) registration:
public class MyWebAppInitializer implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext container) {
AnnotationConfigWebApplicationContext ctx =
new AnnotationConfigWebApplicationContext();
ctx.register(WebConfig.class);
DispatcherServlet dispatcher = new DispatcherServlet(ctx);
ServletRegistration.Dynamic reg =
container.addServlet("dispatcher", dispatcher);
reg.setLoadOnStartup(1);
reg.addMapping("/"); // front controller for all requests
}
}go deeper
Know it's the single entry point (front controller) that delegates to controllers.
Name the special beans it delegates to and that Boot maps it to '/'.
Explain the delegation pipeline and that it's a stateless singleton servlet in the filter chain.
Discuss why centralizing the pipeline matters architecturally and how it composes with the servlet/filter stack and security.
## What it is The **DispatcherServlet** is the heart of Spring MVC (the `spring-webmvc` module). It is a real Java **Servlet** (extends `org.springframework.web.servlet.FrameworkServlet` → `HttpServletBean` → `javax/jakarta.servlet.http.HttpServlet`). It implements the **Front Controller** design pattern. ### Front Controller pattern In plain Servlet apps you might register many servlets, each mapped to a URL, each duplicating boilerplate (parsing, auth checks, view rendering). The Front Controller pattern says: route **every** request through a **single** controller servlet that owns the shared request-processing pipeline and then **delegates** the actual work to per-request handlers. Benefits: one place for cross-cutting behavior (locale resolution, multipart handling, exception mapping, view rendering), and thin controllers that only contain business logic. ### How requests reach it The servlet container (Tomcat/Jetty/Undertow) maps incoming HTTP requests to the DispatcherServlet based on its URL mapping. In Spring Boot the default mapping is `'/'` (everything except other explicitly mapped servlets and static resources handled specially). You can change it with the property `spring.mvc.servlet.path`. ### What it delegates to (the 'special beans') Once a request arrives, DispatcherServlet doesn't do the routing logic itself — it consults a set of collaborating strategy beans it discovers at startup: - **HandlerMapping** — maps a request to a handler (e.g. an `@RequestMapping` method). - **HandlerAdapter** — knows how to actually invoke that handler. - **HandlerExceptionResolver** — turns thrown exceptions into responses. - **ViewResolver / View**, **LocaleResolver**, **ThemeResolver**, **MultipartResolver**, **FlashMapManager**, **RequestToViewNameTranslator**. (These individual strategies are covered in sibling topics — here the point is that DispatcherServlet *orchestrates* them.) ### When you interact with it Most developers never write `DispatcherServlet` code directly — Spring Boot auto-configures and registers it. You touch it when: customizing its URL mapping, registering more than one DispatcherServlet, tuning `throwExceptionIfNoHandlerFound`, or debugging why a request 404s at the framework level. ### Gotchas - It is **not** thread-per-instance: a **single** DispatcherServlet instance serves all requests concurrently; it must be stateless (it is). - 'It's just a servlet' — so it participates in the normal servlet filter chain; Spring Security filters run **before** it. - Static resource requests may be handled by a default servlet, not your controllers, even though the mapping is `'/'`.
- Does DispatcherServlet handle the routing logic itself?No — it orchestrates. It delegates to HandlerMapping to find the handler and HandlerAdapter to invoke it; DispatcherServlet only runs the pipeline.
- How many DispatcherServlet instances exist by default?One, mapped to '/'. You can register multiple, each with its own mapping and its own child WebApplicationContext.
saying these in an interview costs you the question
- Saying each controller is its own servlet
- Thinking DispatcherServlet does URL-to-method matching itself instead of delegating to HandlerMapping
- Claiming it holds per-request state