Based on Spring Framework 4.3.8 RELEASE

[TOC]

由servlet规范可知，servlet容器对一个java web应用解析的入口有以下几种：

servlet容器通过解析以上的一个或多个配置来获取servlet等组件的信息，并将这些组件注册到servletcontext中，以支撑web工作。

Spring MVC作为web的框架，提供由servlet容器解析的配置，有两种方案，一种是使用ServletContextListener的事件监听机制来完成框架的初始化，另一种方式是实现ServletContainerInitializer接口。第一种可以借助web.xml注册listener或者使用注解来注册listener，第二种与web.xml无关，是经由Jar service API来发现的。两种机制是不同的，后者的执行时机是在所有的Listener触发之前。这些都是servlet规范的实现，具体的逻辑都在内部的接口方法实现中。

ServletContextListener是容器生命周期的监听器，启动会触发此监听器的contextInitialized()方法，容器销毁时会触发contextDestroyed()方法。Spring提供了此接口的实现：ContextLoaderListener:

使用ContextLoaderListener方式，只需将此listener注册到ServletContext上即可，即在web.xml中配置此listener。

如果想使用注解来摒弃web.xml配置文件，可以使用如下方式（因为spring的jar包不好直接修改代码加上注解，但是可以通过继承来使用）：

在此方式下，ContextLoaderListener#contextInitialized()是Spring MVC的启动入口。

contextInitialized方法内部调用的是父类ContextLoader的initWebApplicationContext（）方法：

这一步主要逻辑是创建root IOC容器并通过读取配置的spring.xml配置文件初始化，这一步是Spring IOC 容器的启动和初始化，实际上和MVC的关系不大。在实际使用的时候也可以不使用这个root WebApplicationContext，而仅仅使用后面的DispatcherServlet中创建的子容器。之所以使用父子容器，一方面是将不同的bean放到不同的容器中，将如DataSource等通用Bean放在父容器，web专用的bean放在子容器中，一方面结构清晰，也便于更换web框架，另外由于父子容器的访问机制，可以隔离不同的层次。

创建完成后将此WebApplicationContext作为ServletContext的ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE属性置于全局的环境。

由笔记《Servlet和Spring MVC》可知，Listener注册之后是filter的注册，最后是最为核心的Servlet:DispatcherServlet的注册了，web.xml方式下的配置如下：

和前面使用注解来取代此方式的想法一样，我们自定义一个类继承DispatcherServlet：

实际上也可以在前面的listener里面使用ServletContext接口的addServlet()方法来注册servlet。

既然DispatcherServlet也是Servlet，那么必然遵循Servlet规范，在容器启动后会调用其init方法初始化，将其注册到ServletContext上。请求到达时触发service方法来响应请求（通过HttpServlet，一般实现是doGet等方法）。 那么DispatcherServlet的入口也是init方法，先看下它的类结构层次：

从类层次来看，DispatcherServlet间接实现了ApplicationContextAware、EnvironmentCapable、EnvironmentAware接口，说明它能够获取这些aware对象，中间设计的抽象类FrameworkServlet、HttpServletBean填充了具体的通用逻辑，看下init方法（在HttpServletBean中）：

可以看出逻辑就是读取配置的init-param，然后调用模板方法initServletBean()来实现具体的初始化逻辑： 子类FrameWorkServlet的实现：

从DispatcherServlet的初始化过程看，这一步的主要逻辑除了注册servlet外，还有的就是和Spring IOC的融合，创建子容器的逻辑。从Spring MVC的整个流程看，就是在普通的servlet等组件的注册上，结合了Spring IOC的特性，IOC是Spring MVC的基石，很多其他功能都是基于IOC来完成的。

DispatcherServlet的url-pattern匹配一系列的请求url，在内部处理请求的时候会再次分发给各个对应的controller的方法，这部分具体逻辑后面再描述。

此方式是基于jar service API的方法，需要在jar文件内包含/META-INF/services/javax.servlet.ServletContainerInitializer，且该文件内容为ServletContainerInitializer的实现类的全限定名。 在spring-web--RELEASE.jar内包含该文件，文件内容为org.springframework.web.SpringServletContainerInitializer。

此接口的onStartup方法的触发是在ServletContextListener触发之前的，且与web.xml互相独立。也就是初始化流程是：

javadoc中注明了使用规范：

Implementations of this interface may be annotated with * {@link javax.servlet.annotation.HandlesTypes HandlesTypes}, in order to * receive (at their {@link #onStartup} method) the Set of application * classes that implement, extend, or have been annotated with the class * types specified by the annotation. * *

If an implementation of this interface does not use HandlesTypes * annotation, or none of the application classes match the ones specified * by the annotation, the container must pass a null Set of classes * to {@link #onStartup}. * *

When examining the classes of an application to see if they match * any of the criteria specified by the HandlesTypes annontation * of a ServletContainerInitializer, the container may run into * classloading problems if any of the application's optional JAR * files are missing. Because the container is not in a position to decide * whether these types of classloading failures will prevent * the application from working correctly, it must ignore them, * while at the same time providing a configuration option that would * log them. * *

Implementations of this interface must be declared by a JAR file * resource located inside the META-INF/services directory and * named for the fully qualified class name of this interface, and will be * discovered using the runtime's service provider lookup mechanism * or a container specific mechanism that is semantically equivalent to * it. In either case, ServletContainerInitializer services from web * fragment JAR files excluded from an absolute ordering must be ignored, * and the order in which these services are discovered must follow the * application's classloading delegation model. * * @see javax.servlet.annotation.HandlesTypes * * @since Servlet 3.0 */ public interface ServletContainerInitializer { public void onStartup(Set> webAppInitializerClasses, ServletContext servletContext) throws ServletException { List initializers = new LinkedList(); // 找到所有实现WebApplicationInitializer的类，筛去接口和抽象类后把剩下的放入list中 if (webAppInitializerClasses != null) { for (Class waiClass : webAppInitializerClasses) { // Be defensive: Some servlet containers provide us with invalid classes, // no matter what @HandlesTypes says... if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) && WebApplicationInitializer.class.isAssignableFrom(waiClass)) { try { initializers.add((WebApplicationInitializer) waiClass.newInstance()); } catch (Throwable ex) { throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex); } } } } if (initializers.isEmpty()) { servletContext.log("No Spring WebApplicationInitializer types detected on classpath"); return; } servletContext.log(initializers.size() + " Spring WebApplicationInitializers detected on classpath"); AnnotationAwareOrderComparator.sort(initializers); // 调用web应用中的初始化器来执行初始化逻辑，执行初始化器的onStartup()方法 for (WebApplicationInitializer initializer : initializers) { initializer.onStartup(servletContext); } } }

onStartup()方法的内部逻辑很简单，就是找到web中定义的所有WebApplicationInitializer实现类，执行这些初始化类的onStartup()方法来执行初始化逻辑。

接口定义和ServletContainerInitializer相似，Spring中类层次：

从上往下有名字可以确定，Spring提供的三个initializer都是抽象类，所以是没法直接使用的，如果使用此方式来配置使用Spring MVC，需要我们实现（间接）WebApplicationInitializer来完成ServletContainerInitializer中的初始化逻辑。这种方式可以完全摒弃xml配置文件，包括web.xml和spring的xml，可以完全使用JavabBased方式配置。

另外从三个抽象类的名字可以看出，AbstractContextLoaderInitializer主要做的事情是初始化ContextLoaderListener， AbstractDispatcherServletInitializer则是初始化DispatcherServlet；前面两个是主要的初始化器，而且做得事情和之前使用web.xml或者注解来做的注册组件的事情一样，初始化ContextLoaderListener和DispatcherServlet。

AbstractAnnotationConfigDispatcherServletInitializer依然是初始化DispatcherServlet，是给前面两个抽象类的抽象方法的实现，是和@Configuration配置类协作的初始化类，它是使用Java-Based方式使用configClass和注解来配置spring容器的抽象实现（结合AnnotationConfigWebApplicationContext上下文实现）。

简要了解各个实现类的方法：

留给子类实现的抽象方法（模板模式的使用）：

可见此类的主要逻辑是创建根Spring容器，然后注册ServletContextListener（ContextLoaderListener）到ServletContext上，和使用ContextLoaderListener作为入口的方式相似，只是创建IOC容器的逻辑在listener的外面。

抽象方法：

其实类中的其他protected方法都是留给子类重写来自定义逻辑的，是模板方法的大量应用。 如：

此类的主要功能是在父类注册ContextLoaderListener（实际上就是创建RootApplicationContext和设置Listener）的基础上，注册DispaerServlet，以及提供配置映射规则和配置filter和其他自定义注册逻辑，且在这一步创建了DispatcherServlet的IOC容器，和前面web.xml中在DispatcherServlet的init逻辑中创建IOC容器的逻辑类似。

它实现了父类中的两个抽象方法：createRootApplicationContext(),createServletApplicationContext()，也就是Spring MVC中的两个ApplicationContext，可以发现创建的内部逻辑借助了getRootConfigClasses()和getServletConfigClasses()来获取配置class，然后通过AnnotationConfigWebApplicationContext类来创建Context，这些配置类肯定是需要开发者自定义的，自然得交给子类来填充的,且必须填充，很自然的是抽象方法。

This implementation creates an {@link AnnotationConfigWebApplicationContext}, * providing it the annotated classes returned by {@link #getRootConfigClasses()}. * Returns {@code null} if {@link #getRootConfigClasses()} returns {@code null}. */ @Override protected WebApplicationContext createRootApplicationContext() { // 获取根ApplicationContext的配置类 Class[] configClasses = getRootConfigClasses(); if (!ObjectUtils.isEmpty(configClasses)) { // 创建根IOC容器 AnnotationConfigWebApplicationContext rootAppContext = new AnnotationConfigWebApplicationContext(); // 注册配置类 rootAppContext.register(configClasses); return rootAppContext; } else { return null; } } /** * {@inheritDoc} *

This implementation creates an {@link AnnotationConfigWebApplicationContext}, * providing it the annotated classes returned by {@link #getServletConfigClasses()}. */ @Override protected WebApplicationContext createServletApplicationContext() { // 创建DispatcherServlet类的IOC容器，也就是子容器 AnnotationConfigWebApplicationContext servletAppContext = new AnnotationConfigWebApplicationContext(); Class[] configClasses = getServletConfigClasses(); if (!ObjectUtils.isEmpty(configClasses)) { servletAppContext.register(configClasses); } return servletAppContext; } // 交给子类通过配置类的信息 protected abstract Class[] getRootConfigClasses(); protected abstract Class[] getServletConfigClasses(); } 自定义Initializer实现类

自定义实现类一般是实现第三层的抽象类AbstractAnnotationConfigDispatcherServletInitializer，最基本的就是实现父类的两个抽象方法和AbstractDispatcherServletInitializer的getServletMappings() 即可，这些都是需要依据实际的web应用来设置的，如下示例：

一般除此之外可能要添加过滤器或者listener，只需要重写上面的抽象类的某些方法就可以了。除上面必须实现的三个方法之外，还可以重写的方法有：

这些方法的作用都从名字可以明显看出来。

另外如果不想使用AnnotationConfigWebApplicationContext类作为IOC容器的实现类，可以继承AbstractDispatcherServletInitializer实现createServletApplicationContext()和createRootApplicationContext()，在内部实现具体的ApplicationContext创建逻辑。