← Home
BEGINNER → CODING → INTERVIEW

Spring MVC
Complete Interview Guide

Learn Spring MVC from the ground up using one complete Login application. Understand the MVC flow, XML configuration, Controller → Service → DAO, ViewResolver, context hierarchy, Java configuration, complete code files, Mermaid diagrams, interview traps and scenario-based questions.

The flow to remember
BrowserDispatcherServletControllerServiceDAOViewResolverJSP

1. What is MVC?

MVC separates an application into Model, View and Controller so that presentation, request handling and application/data logic do not become one large class.

Model Holds application data and participates in application logic. In our project, LoginBean carries login data.
View Presents the result to the user. Our views are JSP files.
Controller Receives the web request and coordinates the Model and View.
Restaurant memory trick: Browser = customer, Controller = waiter, Service = business decision maker, DAO = database worker, View = final plate.
flowchart LR B["Browser"] --> C["Controller"] C --> S["Service"] S --> D["DAO"] D --> DB["Database"] DB --> D D --> S S --> C C --> V["View"] V --> B

2. Static vs Dynamic Request

Static request Examples: CSS, images, a simple static HTML file.

Server can locate the resource and return it.

Dynamic request Example: POST /validateLogin.html.

The request requires application processing before a response is generated.

flowchart LR B["Browser"] --> S["Web Server"] S --> F["Static Resource"] F --> S S --> B
flowchart LR B["Browser"] --> DS["DispatcherServlet"] DS --> C["Controller"] C --> S["Service"] S --> D["DAO"] D --> S S --> C C --> VR["ViewResolver"] VR --> V["JSP"] V --> B

3. Complete Project We Build

SpringMVCLogin/
│
├── pom.xml
│
├── src/main/java/
│   └── com/example/mvc/
│       ├── model/
│       │   └── LoginBean.java
│       ├── dao/
│       │   └── LoginDAO.java
│       ├── service/
│       │   └── LoginService.java
│       └── controller/
│           └── LoginController.java
│
└── src/main/webapp/
    ├── login.jsp
    └── WEB-INF/
        ├── web.xml
        ├── spring-servlet.xml
        └── views/
            ├── success.jsp
            └── failure.jsp
FileResponsibility
pom.xmlMaven dependencies and WAR build.
web.xmlRegisters and maps DispatcherServlet.
spring-servlet.xmlSpring MVC configuration.
LoginBean.javaModel/data holder.
LoginDAO.javaData-access operation.
LoginService.javaBusiness/service layer.
LoginController.javaHandles the HTTP request.
login.jspLogin form.
success.jspSuccess view.
failure.jspFailure view.

4. Complete Code — Every File

pom.xml

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="
         http://maven.apache.org/POM/4.0.0
         https://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>spring-mvc-login</artifactId>
    <version>1.0</version>

    <!-- Traditional Servlet/Tomcat application -->
    <packaging>war</packaging>

    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
        <spring.version>5.3.39</spring.version>
    </properties>

    <dependencies>

        <!-- Spring MVC -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>${spring.version}</version>
        </dependency>

        <!-- Tomcat supplies this at runtime -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>4.0.1</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>javax.servlet.jsp</groupId>
            <artifactId>javax.servlet.jsp-api</artifactId>
            <version>2.3.3</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>jstl</artifactId>
            <version>1.2</version>
        </dependency>

    </dependencies>

    <build>
        <finalName>spring-mvc-login</finalName>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>3.4.0</version>
            </plugin>
        </plugins>
    </build>

</project>

src/main/webapp/WEB-INF/web.xml

<?xml version="1.0" encoding="UTF-8"?>

<web-app
        xmlns="http://xmlns.jcp.org/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="
        http://xmlns.jcp.org/xml/ns/javaee
        http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
        version="4.0">

    <!-- Welcome page when the application root is opened. -->
    <welcome-file-list>
        <welcome-file>login.jsp</welcome-file>
    </welcome-file-list>

    <!--
        DispatcherServlet is Spring MVC's Front Controller.
        It receives requests and delegates to mapped controllers.
    -->
    <servlet>

        <servlet-name>spring</servlet-name>

        <servlet-class>
            org.springframework.web.servlet.DispatcherServlet
        </servlet-class>

        <!-- Initialize DispatcherServlet during startup. -->
        <load-on-startup>1</load-on-startup>

    </servlet>

    <!--
        Requests ending in .html are handled by DispatcherServlet.
        Example: POST /validateLogin.html
    -->
    <servlet-mapping>

        <servlet-name>spring</servlet-name>

        <url-pattern>*.html</url-pattern>

    </servlet-mapping>

</web-app>

src/main/webapp/WEB-INF/spring-servlet.xml

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:mvc="http://www.springframework.org/schema/mvc"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

       xsi:schemaLocation="
       http://www.springframework.org/schema/beans
       https://www.springframework.org/schema/beans/spring-beans.xsd

       http://www.springframework.org/schema/context
       https://www.springframework.org/schema/context/spring-context.xsd

       http://www.springframework.org/schema/mvc
       https://www.springframework.org/schema/mvc/spring-mvc.xsd">

    <!--
        Scan our application packages for Spring components.

        Spring discovers @Controller, @Service, @Repository,
        and @Component classes.
    -->
    <context:component-scan
            base-package="com.example.mvc"/>

    <!--
        Enables annotation-driven Spring MVC infrastructure.
    -->
    <mvc:annotation-driven/>

    <!--
        Converts a logical view name into a JSP location.

        "success"
            ↓
        /WEB-INF/views/success.jsp
    -->
    <bean
        class="org.springframework.web.servlet.view.InternalResourceViewResolver">

        <property name="prefix">
            <value>/WEB-INF/views/</value>
        </property>

        <property name="suffix">
            <value>.jsp</value>
        </property>

    </bean>

</beans>

src/main/java/com/example/mvc/model/LoginBean.java

package com.example.mvc.model;

/**
 * Model / JavaBean.
 *
 * It carries the login data.
 * It does not decide whether login is valid.
 */
public class LoginBean {

    private String userName;
    private String password;

    public String getUserName() {
        return userName;
    }

    public void setUserName(String userName) {
        this.userName = userName;
    }

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }
}

src/main/java/com/example/mvc/dao/LoginDAO.java

package com.example.mvc.dao;

import com.example.mvc.model.LoginBean;
import org.springframework.stereotype.Repository;

/**
 * DAO = Data Access Object.
 *
 * In a real project this class would normally communicate
 * with a database using JDBC/JPA/etc.
 */
@Repository
public class LoginDAO {

    public boolean validateLogin(LoginBean loginBean) {

        String userName = loginBean.getUserName();
        String password = loginBean.getPassword();

        // Demo credentials only.
        if ("MSD".equals(userName)
                && "MSD@123".equals(password)) {

            return true;
        }

        return false;
    }
}

src/main/java/com/example/mvc/service/LoginService.java

package com.example.mvc.service;

import com.example.mvc.dao.LoginDAO;
import com.example.mvc.model.LoginBean;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

/**
 * Service layer.
 *
 * Business rules should live here rather than inside
 * the controller or DAO.
 */
@Service
public class LoginService {

    private final LoginDAO loginDAO;

    /**
     * Constructor injection.
     * Spring supplies LoginDAO.
     */
    @Autowired
    public LoginService(LoginDAO loginDAO) {
        this.loginDAO = loginDAO;
    }

    public boolean validateLogin(LoginBean loginBean) {

        // Delegate data access to DAO.
        return loginDAO.validateLogin(loginBean);
    }
}

src/main/java/com/example/mvc/controller/LoginController.java

package com.example.mvc.controller;

import com.example.mvc.model.LoginBean;
import com.example.mvc.service.LoginService;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.servlet.ModelAndView;

/**
 * @Controller tells Spring that this is a web controller.
 */
@Controller
public class LoginController {

    private final LoginService loginService;

    @Autowired
    public LoginController(LoginService loginService) {
        this.loginService = loginService;
    }

    /**
     * Handles:
     *
     * POST /validateLogin.html
     */
    @RequestMapping(
            value = "/validateLogin.html",
            method = RequestMethod.POST
    )
    public ModelAndView validateLogin(

            // Reads: <input name="uName">
            @RequestParam("uName")
            String userName,

            // Reads: <input name="pwd">
            @RequestParam("pwd")
            String password
    ) {

        // Create the Model object.
        LoginBean loginBean = new LoginBean();

        // Copy browser data into the Model.
        loginBean.setUserName(userName);
        loginBean.setPassword(password);

        // Controller delegates business work to Service.
        boolean valid = loginService.validateLogin(loginBean);

        ModelAndView modelAndView = new ModelAndView();

        if (valid) {

            // Logical view name, NOT the physical JSP filename.
            modelAndView.setViewName("success");

            // Data made available to success.jsp.
            modelAndView.addObject(
                    "message",
                    "Welcome " + userName
            );

        } else {

            modelAndView.setViewName("failure");

            modelAndView.addObject(
                    "errorMessage",
                    "Invalid username or password"
            );
        }

        // DispatcherServlet receives this result.
        return modelAndView;
    }
}

src/main/webapp/login.jsp

<%@ page contentType="text/html;charset=UTF-8" %>

<!DOCTYPE html>
<html>

<head>
    <title>Spring MVC Login</title>
</head>

<body>

    <h2>Spring MVC Login</h2>

    <!--
        Browser sends POST request to:
        /validateLogin.html
    -->
    <form method="post"
          action="${pageContext.request.contextPath}/validateLogin.html">

        <label>Username:</label>

        <!--
            name="uName" MUST match:
            @RequestParam("uName")
        -->
        <input type="text"
               name="uName"
               required />

        <br><br>

        <label>Password:</label>

        <input type="password"
               name="pwd"
               required />

        <br><br>

        <input type="submit" value="Login" />

    </form>

</body>

</html>

src/main/webapp/WEB-INF/views/success.jsp

<%@ page contentType="text/html;charset=UTF-8" %>

<!DOCTYPE html>
<html>

<head>
    <title>Login Successful</title>
</head>

<body>

    <h2>Login Successful</h2>

    <!-- Comes from ModelAndView.addObject("message", ...). -->
    <h3>${message}</h3>

    <a href="${pageContext.request.contextPath}/login.jsp">
        Back to Login
    </a>

</body>

</html>

src/main/webapp/WEB-INF/views/failure.jsp

<%@ page contentType="text/html;charset=UTF-8" %>

<!DOCTYPE html>
<html>

<head>
    <title>Login Failed</title>
</head>

<body>

    <h2>Login Failed</h2>

    <!-- Comes from Controller's ModelAndView. -->
    <h3>${errorMessage}</h3>

    <a href="${pageContext.request.contextPath}/login.jsp">
        Try Again
    </a>

</body>

</html>

5. Complete MVC Request Flow

Suppose the user enters MSD and MSD@123 and presses Login.

sequenceDiagram participant B as Browser participant T as Tomcat participant DS as DispatcherServlet participant C as LoginController participant S as LoginService participant DAO as LoginDAO participant VR as ViewResolver participant JSP as success.jsp B->>T: POST /validateLogin.html T->>DS: Forward request DS->>C: Find mapped controller method C->>C: Read @RequestParam values C->>S: validateLogin(LoginBean) S->>DAO: validateLogin(LoginBean) DAO-->>S: true S-->>C: true C->>C: Create ModelAndView("success") C-->>DS: ModelAndView DS->>VR: Resolve "success" VR-->>DS: /WEB-INF/views/success.jsp DS->>JSP: Render view JSP-->>B: HTTP response

Step-by-step

  1. Browser submits POST /validateLogin.html.
  2. Tomcat receives the request.
  3. web.xml maps the request to DispatcherServlet.
  4. DispatcherServlet finds the controller method matching the URL and HTTP method.
  5. @RequestParam reads uName and pwd.
  6. Controller creates LoginBean.
  7. Controller calls Service.
  8. Service calls DAO.
  9. DAO returns the result.
  10. Controller creates ModelAndView.
  11. ViewResolver turns success into /WEB-INF/views/success.jsp.
  12. JSP renders the response.
  13. Browser receives the final HTTP response.
Interview flow:
Browser → DispatcherServlet → Controller → Service → DAO → Controller → ModelAndView → ViewResolver → JSP → Browser

6. Important Spring MVC Annotations

AnnotationBeginner meaningUsed in
@Controller Marks a class as a Spring MVC web controller. Controller
@Service Marks a service/business-layer component. Service
@Repository Marks a persistence/data-access component. DAO
@RequestMapping Maps a request URL and optionally its HTTP method. Controller
@RequestParam Reads a request parameter. Controller method parameter
@Autowired Asks Spring to provide a dependency. Dependency injection

7. @RequestMapping and @RequestParam

RequestMapping

@RequestMapping(
    value = "/validateLogin.html",
    method = RequestMethod.POST
)

This says that the method handles a POST request for /validateLogin.html.

RequestParam

@RequestParam("uName")
String userName

The HTML parameter named uName is placed into the Java variable userName.

Common bug: <input name="username"> does not automatically match @RequestParam("uName"). The parameter names must line up unless you explicitly configure another binding strategy.

8. ViewResolver

A controller should normally return a logical view name instead of hard-coding the physical JSP path.

Controller returns:
"success"

        ↓

InternalResourceViewResolver

prefix = /WEB-INF/views/
suffix = .jsp

        ↓

/WEB-INF/views/success.jsp

Important ViewResolver types from the source material

  • UrlBasedViewResolver: direct resolution of logical view names to URLs.
  • InternalResourceViewResolver: JSP/Servlet/JSTL/Tiles resolution using prefix and suffix.
  • ResourceBundleViewResolver: explicit view mappings through a properties file.
  • XmlViewResolver: explicit view mappings through XML.
For this project: Focus on InternalResourceViewResolver.

9. Root / Parent and Child Context

The source material describes two web application contexts: a Root/Parent context for application-wide components and a Servlet/Child context associated with DispatcherServlet.

flowchart TB ROOT["Root / Parent WebApplicationContext"] S["@Service
LoginService"] D["@Repository
LoginDAO"] CHILD["Servlet / Child WebApplicationContext"] C["@Controller
LoginController"] VR["ViewResolver"] ROOT --> S ROOT --> D CHILD --> C CHILD --> VR CHILD -. "can access parent beans" .-> ROOT
Memory rule: Child → Parent access is allowed. Parent should not depend on child-only beans.

Root context responsibilities

  • Application-wide services.
  • Repositories / DAOs.
  • Infrastructure such as security or persistence configuration.

Child / servlet context responsibilities

  • Controllers.
  • ViewResolvers.
  • Web/MVC configuration.

10. ContextLoaderListener

In the traditional two-context configuration, the ContextLoaderListener loads the Root/Parent WebApplicationContext.

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/root-context.xml</param-value>
</context-param>

DispatcherServlet then creates the servlet/child WebApplicationContext.

sequenceDiagram participant T as Tomcat participant W as web.xml participant CL as ContextLoaderListener participant R as Root Context participant DS as DispatcherServlet participant C as Child Context T->>W: Read deployment configuration W->>CL: Initialize listener CL->>R: Load root-context.xml W->>DS: Initialize DispatcherServlet DS->>C: Load MVC context C-->>DS: Web layer ready

11. XML Configuration vs Java Configuration

Spring can express configuration using XML or Java configuration. The important interview point is understanding what each configuration is responsible for rather than memorizing syntax only.

RootConfig.java

package com.example.mvc.config;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

@Configuration
@ComponentScan({
    "com.example.mvc.service",
    "com.example.mvc.dao"
})
public class RootConfig {
}

WebConfig.java

package com.example.mvc.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.EnableWebMvc;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
import org.springframework.web.servlet.view.InternalResourceViewResolver;

@Configuration
@EnableWebMvc
@ComponentScan("com.example.mvc.controller")
public class WebConfig implements WebMvcConfigurer {

    @Bean
    public InternalResourceViewResolver viewResolver() {

        InternalResourceViewResolver resolver =
                new InternalResourceViewResolver();

        resolver.setPrefix("/WEB-INF/views/");
        resolver.setSuffix(".jsp");

        return resolver;
    }
}
Interview memory: XML and Java configuration are two ways of expressing Spring configuration. The architecture remains the same.

12. Custom Spring MVC Context Configuration

If the MVC configuration file does not use the traditional spring-servlet.xml convention, explicitly provide its location to DispatcherServlet.

<servlet>

    <servlet-name>spring</servlet-name>

    <servlet-class>
        org.springframework.web.servlet.DispatcherServlet
    </servlet-class>

    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/config/my-mvc.xml</param-value>
    </init-param>

    <load-on-startup>1</load-on-startup>

</servlet>

The key idea is:

DispatcherServlet
      ↓
contextConfigLocation
      ↓
my-mvc.xml

13. Startup Flow vs Request Flow

Application startup
Tomcat
 ↓
web.xml
 ↓
Context initialization
 ↓
DispatcherServlet
 ↓
Bean creation
 ↓
MVC infrastructure
 ↓
Application ready
Request time
Browser
 ↓
DispatcherServlet
 ↓
Controller
 ↓
Service
 ↓
DAO
 ↓
Controller
 ↓
ViewResolver
 ↓
JSP
 ↓
Browser
Interview trap: Do not explain application startup as if it happens again for every HTTP request. Spring creates and initializes the application context during startup; requests are then dispatched through the initialized infrastructure.

14. Interview Answers — Core Questions

1. Explain Spring MVC flow.
Spring MVC uses DispatcherServlet as the Front Controller. It receives the request, finds the mapped controller method, the controller delegates business work to the service and data access to the DAO, then returns a logical view or ModelAndView. ViewResolver maps the logical view name to the actual view and the response is returned to the client.
2. Why is DispatcherServlet called Front Controller?
Because it acts as a centralized entry point for Spring MVC requests and coordinates request processing instead of every request going directly to an application controller.
3. What does @Controller do?
It identifies a Spring-managed component as a web controller whose methods can handle web requests through Spring MVC's request mapping infrastructure.
4. What does component scanning do?
It scans configured packages and discovers Spring stereotype components such as @Controller, @Service and @Repository so that Spring can register them as beans.
5. Why do we need a Service layer?
It separates business logic from web and persistence concerns. Business rules can therefore evolve without putting them into the controller or DAO.
6. Why use DAO?
DAO isolates data-access logic. The controller and service should not need to know the details of how data is stored or queried.
7. What does @RequestMapping do?
It maps incoming web requests to a controller class or handler method, optionally restricting the HTTP method.
8. What does @RequestParam do?
It binds a request parameter to a controller method parameter, such as mapping HTML parameter uName to a Java String userName.
9. What is ModelAndView?
It is a return value that can carry both the logical view name and model attributes required by that view.
10. What does ViewResolver do?
It translates a logical view name returned by the controller into an actual view resource such as a JSP.
11. What is InternalResourceViewResolver?
It resolves internal resources such as JSP views, commonly using a configured prefix and suffix around the logical view name.
12. Why put JSP files under WEB-INF/views?
It keeps those JSP resources from being directly accessed by the browser and encourages them to be rendered through the MVC flow.
13. What is a root application context?
It is the parent application context commonly used for application-wide components such as services, repositories and infrastructure.
14. What is a child WebApplicationContext?
It is the context associated with DispatcherServlet and commonly contains web-layer components such as controllers and view resolvers.
15. Can child context access parent beans?
Yes. A child context can access beans from its parent.

15. Scenario-Based Interview Questions

Scenario 1 — @Controller exists but is not found
Check whether component scanning covers the controller package, whether the correct application context is loaded, and whether the controller is actually registered as a Spring bean.
Scenario 2 — /validateLogin.html returns 404
Check the DispatcherServlet mapping in web.xml, the controller's @RequestMapping path, the HTTP method, component scanning, and whether the correct context was initialized.
Scenario 3 — username arrives as null/missing
Check that the HTML input's name exactly matches @RequestParam, for example name="uName" with @RequestParam("uName"), and verify the form is actually submitting that parameter.
Scenario 4 — Controller returns "success" but JSP is not found
Check the ViewResolver's prefix and suffix and confirm the physical JSP exists at the resolved path. "success" should resolve to /WEB-INF/views/success.jsp in this project.
Scenario 5 — Developer puts SQL directly in Controller
Move persistence logic into DAO. The controller should handle the web request and delegate business work to the service layer.
Scenario 6 — Service currently only calls DAO
That is still a useful separation. Business rules can be added to the service without changing the controller's responsibility.
Scenario 7 — Removed mvc:annotation-driven
In this XML-based configuration, the MVC annotation infrastructure may not be registered correctly. Verify the MVC configuration and annotation-driven setup.
Scenario 8 — Custom MVC XML filename
Configure DispatcherServlet's contextConfigLocation init parameter with the custom XML path.
Scenario 9 — Parent context tries to access Controller
Reconsider the dependency direction. The child web context can access parent beans, but the parent should not depend on child-only web beans.
Scenario 10 — Why does "success" work without success.jsp in Controller?
Because "success" is a logical view name. InternalResourceViewResolver adds the configured prefix and suffix and locates the actual JSP.
Scenario 11 — Controller contains validation, database calls and HTML
The class has too many responsibilities. Separate request handling, business rules, data access and presentation into Controller, Service, DAO and View respectively.
Scenario 12 — POST request is mapped but GET request fails
Check the method attribute of @RequestMapping. If the handler is restricted to RequestMethod.POST, a GET request will not match it.
Scenario 13 — JSP can be opened directly by URL
Place protected view JSPs under WEB-INF/views and resolve them through the controller/ViewResolver flow rather than exposing them directly.
Scenario 14 — Spring does not inject LoginService into Controller
Check that LoginService is a Spring bean, for example through @Service and component scanning, and that the controller itself is managed by Spring.
Scenario 15 — Application starts but controller mappings fail
Check the DispatcherServlet context, MVC annotation configuration, component scanning and request mappings. Startup success does not guarantee that the expected controller is in the correct context.
Scenario 16 — Two contexts are configured. Where should Controller go?
Put presentation-layer components such as controllers in the child DispatcherServlet context, while application-wide services and DAOs can live in the root context.
Scenario 17 — DAO depends on Controller
That is a poor layering direction. DAO should focus on data access and should not depend on the web/presentation layer.
Scenario 18 — ViewResolver prefix is wrong
The controller can return the correct logical name but resolution will point to the wrong physical location. Verify prefix, suffix and JSP directory structure.
Scenario 19 — Browser sends uName but code expects username
Align the request parameter names or explicitly configure the expected parameter name. Binding depends on the parameter name.
Scenario 20 — Interviewer asks what happens before the first request
The servlet container loads web configuration, Spring contexts are initialized, Spring discovers/configures beans, DispatcherServlet and MVC infrastructure are initialized, and the application becomes ready to process requests.

16. Interview Traps

Trap 1 DispatcherServlet is not the same thing as every Controller. It is the Front Controller that coordinates request processing.
Trap 2 @RequestMapping does not by itself mean the class was discovered as a Spring bean. Component registration still matters.
Trap 3 "success" is a logical view name, not necessarily the JSP filename.
Trap 4 Spring does not force you to create a Service layer. It is an architectural separation used for maintainability.
Trap 5 DAO means Data Access Object, not "database table".
Trap 6 Startup and request processing are different phases.

17. Final Memory Sheet

The one-line flow

Browser
 → DispatcherServlet
 → Controller
 → Service
 → DAO
 → Controller
 → ViewResolver
 → JSP
 → Browser

The configuration memory

web.xml
 ↓
DispatcherServlet

spring-servlet.xml
 ↓
component-scan
 ↓
mvc:annotation-driven
 ↓
ViewResolver

The layer memory

Controller = HTTP / web concern
Service    = business concern
DAO        = data-access concern
Model      = data
View       = presentation

The context memory

Root / Parent
 ├─ Service
 └─ DAO

Child / DispatcherServlet
 ├─ Controller
 └─ ViewResolver

Child can access Parent.

The ViewResolver memory

"success"
   +
prefix: /WEB-INF/views/
   +
suffix: .jsp
   =
/WEB-INF/views/success.jsp
Interview-ready sentence:
Spring MVC uses DispatcherServlet as the Front Controller. It dispatches requests to mapped controllers, which delegate business logic to services and data access to DAOs. The controller returns a logical view name or ModelAndView, and ViewResolver resolves that logical name to the actual view.
Practice task: Close this page and try writing web.xml, spring-servlet.xml, Controller → Service → DAO and the three JSPs from memory. Then explain the request flow aloud without looking at the diagram.

18. Source-Aligned Coverage

This guide follows the uploaded Spring MVC material's terminology and coverage around Model2/MVC, dynamic request flow, DispatcherServlet, Controller/Service/DAO, context configuration, Root/Child context hierarchy, ViewResolver, InternalResourceViewResolver and Java configuration.

Where this guide uses a concrete Login project, the implementation is used as the teaching example so the concepts can be connected into one complete application rather than learned as isolated definitions.