The DispatcherServlet is always declared as a typical <servlet> in any Tomcat servlet container. But more than a servlet, DispatcherServlet is the core servlet handler of any Spring MVC application which controls request dispatch processing and responses for each web transaction. It has a WebApplicationContext that manages @Controllers, @RequestMapping, and view resolvers for every HTTP/2 transaction.
To enable WebApplicationContext, DispatcherServlet must have a lookup configuration document known as the XML-based Spring definition file, which needs to be loaded to the servlet container also. In this project, ch02-servlet.xml serves as the root context definition file, which is just a typical ApplicationContext definition from our previous recipes.
As the project progresses, many custom and extension servlets (for example, WSServlet, ServletContainer) will be added to Tomcat's servlet container. In order to initially load DispatcherServlet among all the others, we indicate <load-on-startup> to have a value of the rest of the servlets; they must have values greater than 1 to prioritize the loading of our main servlet.
The next step in the configuration is the creation of the view resolver beans. The InternalResourceViewResolver is the easiest to set up but the most unreliable to use. It requires physical view pages to be compiled inside WEB-INF and must only use one technology, JSP. Also, it requires that the filenames of the JSP pages should be the same with the view name redirected by the @Controller. And whenever you inject more than one view resolver, InternalResourceViewResolver is always called first because it is one of the default configurations of DispatcherServlet. Since we have injected MessageResourceViewResolver also, the former must be executed last by setting its priority <order> property to 1 while MessageResourceViewResolver must have 0, the highest priority order level. The MessageResourceViewResolver needs the views.properties configuration to work.
After the view layer, @Controllers and its @RequestMapping handlers must be created to manage the request and response transactions. Avoid duplicate URL path names and view names must be valid ones.
To enable the use of annotations inside classes, <mvc:annotation-driven /> must appear in the context definition. It tells WebApplicationContext that there are classes that utilize both Spring-proprietary and JSR-330 annotations essential for the application. Lastly, to tell WebApplicationContext what classes use these annotated features on object auto-wiring, the Classpath root package must be declared in <context:component-scan base-package="org.packt.starter.ioc"/> metadata.