Introduction

In classic Spring MVC applications, web.xml was the place where DispatcherServlet and other web components were registered. Spring Boot changes that model by auto-configuring the servlet container and registering DispatcherServlet for you, so in most Boot applications there is no reason to create a web.xml file at all.

What DispatcherServlet Does

DispatcherServlet is the front controller of Spring MVC. Every incoming request mapped to it flows through the same core steps:

1. find a matching controller method
2. bind request data to method parameters
3. invoke the handler
4. select a view or write a response body
5. apply exception resolvers and interceptors if needed

In a Boot application with spring-boot-starter-web, this servlet is created automatically and mapped to / unless you override the default configuration.

That default matters because it keeps controller discovery, message conversion, validation, and exception handling aligned with the rest of Boot's MVC auto-configuration. You are not only getting a servlet instance, you are getting the surrounding MVC infrastructure wired around it.

Spring Boot Replaces Most web.xml Use Cases

A minimal Boot application needs only the application class and a controller.

1package com.example.demo;
2
3import org.springframework.boot.SpringApplication;
4import org.springframework.boot.autoconfigure.SpringBootApplication;
5import org.springframework.web.bind.annotation.GetMapping;
6import org.springframework.web.bind.annotation.RestController;
7
8@SpringBootApplication
9public class DemoApplication {
10    public static void main(String[] args) {
11        SpringApplication.run(DemoApplication.class, args);
12    }
13}
14
15@RestController
16class HelloController {
17    @GetMapping("/hello")
18    public String hello() {
19        return "hello";
20    }
21}

There is no web.xml here because Boot uses Java configuration and auto-configuration instead of deployment descriptor wiring.

Customizing DispatcherServlet in Boot

If you need custom registration, Boot still allows it. You can declare a DispatcherServlet bean and register it with a custom path.

1package com.example.demo;
2
3import org.springframework.boot.web.servlet.ServletRegistrationBean;
4import org.springframework.context.annotation.Bean;
5import org.springframework.context.annotation.Configuration;
6import org.springframework.web.servlet.DispatcherServlet;
7
8@Configuration
9public class WebConfig {
10
11    @Bean
12    public DispatcherServlet dispatcherServlet() {
13        DispatcherServlet servlet = new DispatcherServlet();
14        servlet.setThrowExceptionIfNoHandlerFound(true);
15        return servlet;
16    }
17
18    @Bean
19    public ServletRegistrationBean<DispatcherServlet> dispatcherServletRegistration(
20        DispatcherServlet dispatcherServlet
21    ) {
22        return new ServletRegistrationBean<>(dispatcherServlet, "/api/*");
23    }
24}

That pattern covers most advanced servlet registration needs that web.xml used to handle.

You can also change common properties in configuration:

spring.mvc.servlet.path=/api
spring.web.resources.add-mappings=false

For many projects, property-based customization is enough.

When web.xml Still Appears

You may still see web.xml in older applications or in projects packaged as WAR files for deployment to an external servlet container. Even then, Spring Boot usually prefers Java-based initialization through SpringBootServletInitializer.

1package com.example.demo;
2
3import org.springframework.boot.builder.SpringApplicationBuilder;
4import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;
5
6public class ServletInitializer extends SpringBootServletInitializer {
7    @Override
8    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
9        return application.sources(DemoApplication.class);
10    }
11}

That class replaces a large part of what web.xml used to do when deploying outside an embedded server.

Common Pitfalls

The most common confusion is trying to define both Boot auto-configuration and manual web.xml servlet mappings for the same application. That creates duplicate registration paths and makes request routing harder to reason about.

Another problem is assuming DispatcherServlet is the same as the embedded server. It is not. Tomcat, Jetty, or Undertow accepts the socket connection. DispatcherServlet then handles MVC request dispatch inside the application.

Developers also sometimes customize the servlet path and forget that actuator endpoints, static resources, or security configuration may need corresponding updates. Changing / to /api/* is not just a cosmetic change.

Finally, if you migrate an old Spring MVC project into Boot, do not copy web.xml blindly. Start from Boot defaults, then add only the custom behavior you still need. Boot removes a lot of old configuration boilerplate, and reintroducing it without a reason usually creates maintenance debt.

Summary

• 'DispatcherServlet is the Spring MVC front controller.'
• Spring Boot auto-registers it, so most Boot apps do not need web.xml.
• Use Java configuration or Boot properties when you need custom servlet behavior.
• For WAR deployment, prefer SpringBootServletInitializer over descriptor-heavy setup.
• Avoid mixing legacy web.xml patterns with Boot defaults unless you have a specific deployment requirement.