Spring MVC

web.xml

    <context-param>
        <description>Spring config files</description>
        <param-name>contextConfigLocation</param-name>
        <param-value>
            /WEB-INF/beans/*.xml
        </param-value>
    </context-param>
    <!--
     The ContextLoaderListener listener loads the Spring ApplicationContext container beans from XML files. It uses the contextConfigLocation web application context parameter from above to know what
     XML bean files to load into the container.
     -->
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <servlet>
        <servlet-name>springMvcDispatcher</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
         <!- If the location is not defined, it default to <servlet-Name>-servlet.xml -->
          <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/beans/dispatcherServlet.xml</param-value>
        </init-param>
      <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>

        <servlet-name>springMvcDispatcher</servlet-name>

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

    </servlet-mapping>

<servlet-name>-servlet.xml

Bean type	Explanation
controllers	Form the C part of the MVC.
handler mappings	Handle the execution of a list of pre-processors and post-processors and controllers that will be executed if they match certain criteria (for example, a matching URL specified with the controller).
view resolvers	Resolves view names to views.
locale resolver	A locale resolver is a component capable of resolving the locale a client is using, in order to be able to offer internationalized views
Theme resolver	A theme resolver is capable of resolving themes your web application can use, for example, to offer personalized layouts
multipart file resolver	Contains functionality to process file uploads from HTML forms.
handler exception resolvers	Contains functionality to map exceptions to views or implement other more complex exception handling code.

after locae resolver, theme resolver, multipart resolver

1. An appropriate handler is searched for. If a handler is found, the execution chain associated with the handler (preprocessors, postprocessors, and controllers) is executed in order to prepare a model or rendering.
   
2. If a model is returned, the view is rendered. If no model is returned, (may be due to a preprocessor or postprocessor intercepting the request, perhaps for security reasons), no view is rendered, because the request could already have been fulfilled
   
   

HandlerMapping 

First method:  DispatcherServlet enables the DefaultAnnotationHandlerMapping, which looks for @RequestMapping annotations on @Controllers. Typically, you do not need to override this default mapping, unless you need to override the default property values

   <!--
     URL to Controller mappings.
     Defines the mapping of a HTTP request URL to a Spring MVC controller class that is designated to handle the HTTP request.
     Add a property to this bean for each new URL/Controller combination that is defined. Like the property in blue.
     -->
    <bean id="urlToControllerMappings" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">

        <property name="mappings">
            <props>
                <prop key="/users.html">userController</prop> 
                <prop key="/editUser.html">userFormController</prop>
                <prop key="/fileUpload.html">fileUploadController</prop>
                <prop key="/userReport.*">reportController</prop>
            </props>
        </property>

    </bean>

Second method:  <mvc:annotation-driven/>

This tag registers the DefaultAnnotationHandlerMapping and 
AnnotationMethodHandlerAdapter beans that are required for Spring MVC to 
dispatch requests to @Controllers

ViewResolver

Spring supports multiple view resolvers. Thus you can chain resolvers. You chain view resolvers by adding more than one resolver to your application context and, if necessary, by setting the order property to specify ordering. Remember, the higher the order property, the later the view resolver is positioned in the chain.

<bean id="viewResolver"
      class="org.springframework.web.servlet.view.UrlBasedViewResolver">
    <property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
    <property name="prefix" value="/WEB-INF/jsp/"/>
    <property name="suffix" value=".jsp"/>
</bean>

<bean id="viewResolver"
      class="org.springframework.web.servlet.view.ResourceBundleViewResolver">
    <property name="order" value="1"/>

<property name="basename" value="views"/>
    <property name="defaultParentView" value="parentView"/>
</bean>

<bean id="excelViewResolver" class="org.springframework.web.servlet.view.XmlViewResolver">
  <property name="order" value="2"/>
  <property name="location" value="/WEB-INF/views.xml"/>
</bean>

<bean id="jspViewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
  <property name="order" value="3"/>

<property name="prefix" value="/WEB-INF/jsp/"/>
  <property name="suffix" value=".jsp"/>
</bean>

Then order is ResourceBundleViewResolver, XmlViewResolver, InternalResourceViewResolver, UrlBasedViewResolver

Note: When chaining ViewResolvers, a UrlBasedViewResolver always needs to be last, as it will attempt to resolve any view name, no matter whether the underlying resource actually exists.

Note: use the InternalResourceViewResolver instead of the UrlBasedViewResolver, which remove the need to specify viewClass.