Spring MVC Architecture & DispatcherServlet — Interview Questions

How to use this lesson

Every Spring MVC question leads back to one diagram: request → DispatcherServlet → HandlerMapping → HandlerAdapter → Controller → (view or message converter) → response. Learn it once, and you can answer all nine questions below. In Spring Boot, most of the configuration is automatic, but interviewers still ask how it works underneath.

Q1. What is Spring MVC?

Short answer: Spring MVC is Spring's servlet-based web framework, built around the Model–View–Controller pattern and a central front controller, the DispatcherServlet. Controllers handle requests, the model carries data, and views render HTML. For REST APIs, message converters write JSON instead of rendering a view.

Key points to cover:

• It provides request mapping, data binding, validation, content negotiation, exception handling, interceptors, file upload and internationalisation.
• In Spring Boot it's auto-configured by spring-boot-starter-web.

Learn it in depth → REST Controllers

Q2. What are the core components of Spring MVC?

Short answer:

• DispatcherServlet: the front controller.
• HandlerMapping: finds which handler matches the request.
• HandlerAdapter: invokes the handler.
• Controller: your @Controller or @RestController.
• Model: the data for the view.
• ViewResolver: turns a view name into a View.
• View: renders the output.
• HttpMessageConverters: convert JSON and XML.
• HandlerExceptionResolvers: handle errors.
• HandlerInterceptors: pre- and post-processing.

Q3. Describe the lifecycle of a Spring MVC request.

Short answer:

1. The servlet container passes the request through its filters (security, CORS, encoding) to the DispatcherServlet.
2. The DispatcherServlet asks each HandlerMapping for a handler. RequestMappingHandlerMapping matches @RequestMapping methods, and the handler comes back wrapped in an execution chain with any interceptors.
3. The interceptors' preHandle methods run.
4. A HandlerAdapter invokes the controller method. Argument resolvers bind path variables, parameters and the request body (using message converters), and run validation.
5. The controller returns one of two things:
   • a view name plus a model: the ViewResolver finds the View, which renders HTML;
   • a body (@ResponseBody/@RestController): an HttpMessageConverter writes JSON directly.
6. The interceptors' postHandle and afterCompletion methods run. If an exception occurred, the exception resolvers (@ExceptionHandler/@ControllerAdvice) produce the error response.

Client → Filters → DispatcherServlet → HandlerMapping → Interceptors.preHandle
       → HandlerAdapter → Controller → (ViewResolver → View | MessageConverter → JSON)
       → Interceptors.postHandle/afterCompletion → Response

Q4. What role does the DispatcherServlet play? How are controllers and view resolvers wired together during a request?

Short answer: The DispatcherServlet is the front controller. Every request goes through it, and it orchestrates the whole flow: it delegates handler lookup to HandlerMappings, invocation to HandlerAdapters, view resolution to ViewResolvers, and errors to HandlerExceptionResolvers. It doesn't do any of that work itself. That's what makes each step pluggable, following the Strategy pattern.

Key points to cover:

• At startup, it discovers these strategy beans in its WebApplicationContext. It falls back to defaults (DispatcherServlet.properties) when none are defined. Spring Boot auto-configuration registers the standard ones.
• Because a single servlet dispatches everything, cross-cutting concerns such as locale, themes, multipart parsing and exception handling are applied consistently to every request.

Q5. What is the role of the WebApplicationContext?

Short answer: It's an ApplicationContext that is aware of the web environment. It knows its ServletContext, and it supports the request, session and application scopes. The DispatcherServlet loads its MVC beans (controllers, view resolvers, handler mappings) from it.

Key points to cover:

• In classic (non-Boot) setups there was a hierarchy:
  • a root context, loaded by ContextLoaderListener, with services, repositories and data sources;
  • a child servlet context per DispatcherServlet, with web beans.
  • Child contexts can see beans in the root context, but not the other way round.
• Spring Boot normally uses a single context for everything.

Q6. How do you configure Spring MVC in a web application?

Short answer: In Spring Boot: add spring-boot-starter-web, and you're done. The DispatcherServlet, Jackson converters, static-resource handling and error pages are all auto-configured. Customise them by implementing WebMvcConfigurer.

In classic Spring:

1. Register the DispatcherServlet, in web.xml or a WebApplicationInitializer.
2. Enable MVC with @EnableWebMvc (or <mvc:annotation-driven/>).
3. Enable component scanning for controllers.
4. Declare a ViewResolver (for JSP or Thymeleaf).

@Configuration
class WebConfig implements WebMvcConfigurer {                // Boot: customise without @EnableWebMvc
    @Override public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new RequestTimingInterceptor()).addPathPatterns("/api/**");
    }
    @Override public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**").allowedOrigins("https://shop.example.com");
    }
}

Common trap: adding @EnableWebMvc in a Boot application to "turn on MVC". It disables Boot's MVC auto-configuration, so you lose the Jackson settings, static resources and more.

Q7. What role does web.xml or Java config play in setting up Spring MVC?

Short answer: It's where the servlet container is told about Spring. It declares the DispatcherServlet and its URL mapping (usually /), points it at its configuration, and optionally registers ContextLoaderListener and filters. Java config does the same thing in code, through WebApplicationInitializer.

<servlet>
    <servlet-name>app</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/app-servlet.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>app</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

Q8. How do you set up Spring MVC without web.xml?

Short answer: Servlet 3.0+ containers discover a WebApplicationInitializer automatically. The easiest route is to extend AbstractAnnotationConfigDispatcherServletInitializer:

public class AppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
    @Override protected Class<?>[] getRootConfigClasses()    { return new Class<?>[] { ServiceConfig.class }; }
    @Override protected Class<?>[] getServletConfigClasses() { return new Class<?>[] { WebConfig.class }; }  // @EnableWebMvc here
    @Override protected String[] getServletMappings()        { return new String[] { "/" }; }
}

Key points to cover:

• With Spring Boot and an embedded server, you need neither of these. Boot registers the DispatcherServlet as a bean. For WAR deployment you extend SpringBootServletInitializer.

Q9. How do servlets and listeners contribute to the configuration?

Short answer:

• Servlets handle requests. The DispatcherServlet is the servlet in a Spring MVC app.
• Listeners react to lifecycle events. ContextLoaderListener creates the root application context when the web app starts, and closes it on shutdown. RequestContextListener exposes the current request to non-MVC code.
• Filters wrap every request. Spring Security's DelegatingFilterProxy, CharacterEncodingFilter and CORS filters are the common examples.

Follow-up questions this topic invites — and their answers

Q: What's the difference between a filter and an interceptor? A: Filters are part of the Servlet API, and run before the DispatcherServlet, on every request, including static resources. They're used for security, encoding, CORS and logging. Interceptors are Spring MVC components that run around handler execution, with access to the chosen handler. They're used for per-controller concerns such as auditing and timing.

Q: Can you have more than one DispatcherServlet? A: Yes, each with its own context and URL mapping (for example /api/* and /admin/*). It's rarely needed today.

Q: How does Spring MVC choose the JSON library? A: Through registered HttpMessageConverters. With Jackson on the classpath, MappingJackson2HttpMessageConverter handles application/json, based on the request's Content-Type and Accept headers.

Q: Is Spring MVC thread-safe? A: Each request runs on its own container thread, and controllers are singletons. So controllers must be stateless, just like any singleton service.