Question 1 of 5 · senior level

Trace an HTTP request through Spring MVC — what does the DispatcherServlet actually do?

🎤 Say this first

Everything enters one front controller. The DispatcherServlet asks its HandlerMappings which handler matches (annotation mapping resolves @GetMapping etc.), gets the handler + interceptor chain, then a HandlerAdapter invokes the controller method — argument resolvers materialize parameters (@PathVariable, @RequestBody via HttpMessageConverters, validation), and the return value goes back out through a ReturnValueHandler: for REST, a message converter (Jackson) writes JSON; for server-rendered views, a ViewResolver renders. Exceptions route through HandlerExceptionResolvers (@ControllerAdvice). It's the front controller pattern with every step a replaceable strategy.

The full picture

🎬 Spring MVC: journey of a request

1 / 6

GET /orders/42 arrives. Every request enters through ONE servlet — the DispatcherServlet (front controller pattern). Filters (security, CORS) already ran before it.

Client → DispatcherServlet → mapping → adapter → controller → converter → response.

Before the servlet: the Filter chain (container-level) — Spring Security lives here, outside MVC. Interceptors run inside, around the handler.
Argument resolution is the underrated half: HandlerMethodArgumentResolvers turn the raw request into your typed signature; you can register custom ones (e.g., @CurrentUser User user).
Content negotiation picks the converter via Accept header/produces — the same controller can emit JSON or XML without code changes.
Boot's role: auto-configures the DispatcherServlet, sensible converters, and error handling — the machinery is Framework; the pre-wiring is Boot.

🔄 Likely follow-up questions

Where exactly does Spring Security sit relative to the DispatcherServlet?
What happens when no handler matches? (404 path, NoHandlerFoundException nuances)
How does the async request model (DeferredResult/Callable) change this flow?