DispatcherServlet

Understand the idea

After relevant filters run, it identifies the handler for a route, invokes that handler through MVC infrastructure, and coordinates the response. A view resolver and template engine handle an HTML response; message converters handle objects returned by REST controllers.

A concrete example

HTTP request
→ security filters
→ DispatcherServlet
→ mapped controller method

In the application

Already in Stage 1, Boot configures DispatcherServlet and registers it with embedded Tomcat. GET /aboutus.html is processed through MVC’s built-in static-resource handler; no custom controller is needed. Stage 2 adds PageController for GET /aboutus. Later product routes use our @GetMapping and @PostMapping methods.

Spring MVC still runs on Servlet infrastructure. Your existing knowledge of requests, responses, sessions, and filters remains useful.

Start in Stage 1: two containers, two jobs

Spring Boot configures DispatcherServlet as a bean and registers it with Tomcat in this MVC application. Having a Spring container alone does not imply a DispatcherServlet; a background-only application may not need one.

Stage 1 serves a static file without our own controller

GET /aboutus.html
→ Tomcat
→ DispatcherServlet
→ built-in Spring MVC static-resource handler
→ static/aboutus.html
→ HTML response to the browser

Spring supplies the handler for static files. DispatcherServlet delegates the work; it does not itself read every file or contain application business rules.

Stage 2 adds our controller

GET /aboutus selects PageController.aboutUs(). The controller is the application handler for that route. DispatcherServlet continues coordinating the request. The direct /aboutus.html address still uses the static-file handler.

See it in a working stage

• Stage 1: serve Home and About Us as static HTML
• Stage 2: let a controller handle a request

Related concepts

• MVC · Model–View–Controller
• Controller
• HTTP
• ApplicationContext
• Apache Tomcat