HandlerAdapter Invocation

## The problem it solves Spring MVC's front controller is `DispatcherServlet`. For every request it runs a fixed pipeline: resolve a **handler** (via `HandlerMapping`), **invoke** that handler, then render the result. The catch is that a "handler" can be many different things: - An `@RequestMapping`/`@GetMapping` **method** on a `@Controller` (by far the most common). - A bean implementing the older `org.springframework.web.servlet.mvc.Controller` interface. - A bean implementing `HttpRequestHandler` (low-level access to `HttpServletRequest`/`HttpServletResponse`). - A functional `RouterFunction` endpoint. Each shape is invoked differently. Rather than putting `if (handler instanceof ...)` chains inside `DispatcherServlet`, Spring uses the **Adapter pattern** via the `HandlerAdapter` interface. ## The interface ```java public interface HandlerAdapter { boolean supports(Object handler); ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception; // long getLastModified(...) — deprecated since 6.0 } ``` - `supports(handler)` — can this adapter invoke that handler object? - `handle(...)` — actually invoke it and return a `ModelAndView` (which may be `null` when the response is already fully written, e.g. `@ResponseBody`). ## How DispatcherServlet uses it Inside `DispatcherServlet.doDispatch(...)` the flow is roughly: 1. `mappedHandler = getHandler(request)` — a `HandlerExecutionChain` (handler + interceptors). 2. `HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler())` — loops over the `handlerAdapters` list and returns the first whose `supports()` is true; throws `ServletException` if none match. 3. Applies interceptor `preHandle`. 4. `mv = ha.handle(request, response, handler)` — the actual invocation. 5. Applies `postHandle`, then renders the `ModelAndView`. ## The concrete adapters - **`RequestMappingHandlerAdapter`** — invokes annotated `@RequestMapping` handler methods; where argument resolvers and return-value handlers live. The one you almost always use. - **`HttpRequestHandlerAdapter`** — for `HttpRequestHandler` beans. - **`SimpleControllerHandlerAdapter`** — for beans implementing `Controller`. - **`HandlerFunctionAdapter`** — for functional (`RouterFunction`) endpoints. With Spring Boot / `@EnableWebMvc`, these are auto-registered and ordered. ## Gotchas - The `handle` return of `null` is normal, not an error — it signals the response was already written (REST/`@ResponseBody`), so no view rendering is needed. - `HandlerMapping` and `HandlerAdapter` are **separate** responsibilities: mapping decides *which* handler, adapter decides *how to call it*. Candidates often conflate them. - The first matching adapter wins, so ordering matters, but in practice each `supports()` is specific enough that there is no overlap. ## When to care Day to day you never touch this — it's plumbing. You care when you register a custom handler type, debug a `"No adapter for handler"` `ServletException`, or explain the request lifecycle in an interview.