In the first chapter, we provided a little introduction to the Dispatcher servlet and you saw how to configure a Dispatcher servlet using the DispatcherServletInitializer class. You learned that every web request first comes to the Dispatcher servlet. The Dispatcher servlet is the thing that decides which controller method the web request should be dispatched to. In the previous chapter, we created a welcome page that will be shown whenever we enter the URL http://localhost:8080/webstore/ in the browser. Mapping a URL to the appropriate controller method is the primary duty of the Dispatcher servlet.

So the Dispatcher servlet reads the web request URL and finds the appropriate controller method that can serve that web request and invokes it. This process of mapping a web request onto a specific controller method is called request mapping. And the Dispatcher servlet is able to do this with the help of the @RequestMapping (org.springframework.web.bind.annotation.RequestMapping...

Now we've got a basic idea of how request mapping works. I also mentioned that every web request first comes to the Dispatcher servlet, but the question is how does the Dispatcher servlet know it should handle every incoming request? The answer is we explicitly instructed it to do so through the getServletMappings method of the DispatcherServletInitializer class. Yes, when we return the string array containing only the "/" character, it indicates the DispatcherServlet configuration as the default servlet of the application. So every incoming request will be handled by DispatcherServlet.

The servlet mapping specifies which web container of the Java servlet should be invoked for a given URL. It maps the URL patterns to servlets. When there is a request from a client, the servlet container decides which servlet it should forward the request to based on the servlet mapping. In our case, we mapped all incoming requests to DispatcherServlet.

In contrast, request mapping guides the DispatcherServlet which controller method it needs to invoke as a response to the request based on the request path. In our case, we mapped the /welcome request path to the welcome method of the HomeController class.

@Override 
protected String[] getServletMappings() { 
   return new String[] { "*.do"}; 
} 

In a Spring-based application, our application objects will live within an object container. This container will create objects and associations between objects and manage their complete lifecycle. These container objects are called Spring managed beans (or simply beans) and the container is called application context in the Spring world.

Spring's container uses dependency injection (DI) to manage the beans that make up an application. An application context (org.springframework.context.ApplicationContext) creates beans, associates beans together based on bean configuration, and dispenses beans upon request. A bean configuration can be defined via an XML file, annotation, or even via Java configuration classes. We are going to use annotation and Java configurations in our chapters.

A web application context is an extension of the application context, and is designed to work with the standard servlet context (javax.servlet.ServletContext). The web application context...

A view resolver helps the Dispatcher servlet to identify the views that have to be rendered as a response to a specific web request. Spring MVC provides various view resolver implementations to identify views and InternalResourceViewResolver is one such implementation:

@Bean 
public InternalResourceViewResolver getInternalResourceViewResolver() { 
    InternalResourceViewResolver resolver = new InternalResourceViewResolver(); 
    resolver.setViewClass(JstlView.class); 
    resolver.setPrefix("/WEB-INF/jsp/"); 
    resolver.setSuffix(".jsp"); 
 
    return resolver; 
} 

Through the above bean definition is in the web application context configuration (WebApplicationContextConfig), we are instructing Spring MVC to create a bean for the class InternalResourceViewResolver (org.springframework.web.servlet.view.InternalResourceViewResolver). We will see more about the view resolver in Chapter 5, Working with View Resolver.

The web application context configuration file (WebApplicationContextConfig.java) is nothing but a simple Java-based Spring bean configuration class. Spring will create beans (objects) for every bean definition mentioned in this class during the boot up of our application. If you open this web application context configuration file, you will find the following annotations on top of the class definition:

The first annotation @Configuration indicates that this class declares one or more @Bean methods. If you remember, in the last section, I explained how we created a bean definition for InternalResourceViewResolver.

The second annotation is @EnableWebMvc. With this...

So far, we have looked at lots of concepts such as the Dispatcher servlet, request mapping, controllers, and the view resolver, but it would be good to see the overall picture of the Spring MVC request flow so that we can understand each component's responsibilities. But before that, you need a basic understanding of the Model View Controller (MVC) concept. Every enterprise level application's Presentation layer can be logically divided into three major parts:

The following diagram should help you to understand the event flow and command flow within an MVC pattern.

The classic MVC pattern

Whenever a user interacts with the view by clicking on a link or button, or something similar, the view issues an event notification to the controller and the controller issues a command notification...

The main entry point for a web request in a Spring MVC application is via the Dispatcher servlet. The Dispatcher servlet acts as a front controller and dispatches the requests to the other controller. The front controller's main duty is to find the appropriate right controller to hand over the request for further processing. The following diagram shows an overview of the request flow in a Spring MVC application:

The Spring MVC request flow

Okay, let's review the Spring MVC request flow in short: