Servlet3.0

Servlet3.0是基于注解配置的实践根底。

Servlet3.0引入了基于注解配置Servlet的标准，提出了可拔插的ServletContext初始化形式，引入了一个叫ServletContainerInitializer的接口。

An instance of the ServletContainerInitializer is looked up via the jar services API by the container at container / application startup time. The framework providing an implementation of the ServletContainerInitializer MUST bundle in the META-INF/services directory of the jar file a file called javax.servlet.ServletContainerInitializer, as per the jar services API, that points to the implementation class of the ServletContainerInitializer.

Servlet3.0标准约定：WEB容器（比方tomcat）要通过SPI的形式查看利用jar包的META-INF/services目录下的Servlet容器的初始化类（ServletContainerInitializer接口的实现类），通过调用该实现类的onStartup办法实现Servlet容器的初始化。

此外，Servlet3.0还引入了@HandlesTypes注解，用来指定Servlet容器初始化过程中，WEB容器会认为利用中的哪些类（由@HandlesTypes指定）会参加到Servlet容器的初始化过程中来。

SpringMVC正是通过以上形式实现Servlet容器的初始化的！！！

SpringMVC Servlet容器初始化过程

依照上述实践的指引，探索注解形式配置Spring MVC的原理就没那么艰难了。

先看下图：

很容易的，咱们发现SpringMVC指定的Servlet容器初始化的实现类为org.springframework.web.SpringServletContainerInitializer。

所以咱们找到他看看：

@HandlesTypes(WebApplicationInitializer.class)public class SpringServletContainerInitializer implements ServletContainerInitializer {}

的确是ServletContainerInitializer接口的实现类，@HandlesTypes指定的是WebApplicationInitializer，这个WebApplicationInitializer到底是个啥东东，咱们先放放，咱们先来钻研一下 SpringServletContainerInitializer类的onStartup办法。

@Override    public void onStartup(@Nullable Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)            throws ServletException {        List<WebApplicationInitializer> initializers = new LinkedList<>();        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)                                ReflectionUtils.accessibleConstructor(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);        for (WebApplicationInitializer initializer : initializers) {            initializer.onStartup(servletContext);        }    }}

代码逻辑也不算简单，查看传入的参数webAppInitializerClasses，如果是实现类的话（不是接口或抽象类）则通过反射机制实例化webAppInitializerClasses并强转为WebApplicationInitializer，而后调用WebApplicationInitializer的onStartup办法。

这里有一个小问题：参数webAppInitializerClasses实例化之后，为什么能强转为WebApplicationInitializer？

其实这也是Servlet3.0标准约定的，WEB容器会依据@HandlesTypes的设置，从以后类加载器中查找符合条件的类，以后@HandlesTypes指定的正是WebApplicationInitializer。

之后的操作就都交给WebApplicationInitializer了。

WebApplicationInitializer

WebApplicationInitializer是承当起Servlet3.0标准约定的初始化Servlet容器的那个人：

Interface to be implemented in Servlet 3.0+ environments in order to configure the ServletContext programmatically -- as opposed to (or possibly in conjunction with) the traditional web.xml-based approach.
Implementations of this SPI will be detected automatically by SpringServletContainerInitializer, which itself is bootstrapped automatically by any Servlet 3.0 container. See its Javadoc for details on this bootstrapping mechanism.

咱们先看一下他的类构造：

Spring框架实现了WebApplicationInitializer接口的3个抽象类，最初一个抽象类AbstractAnnotationConfigDispatcherServletInitializer没有onStartup办法，onStartup办法是他的父类实现的。

咱们看一下他的父类AbstractDispatcherServletInitializer的onStartup办法：

    @Override    public void onStartup(ServletContext servletContext) throws ServletException {        super.onStartup(servletContext);        registerDispatcherServlet(servletContext);    }

能够发现他其实是一个模板办法，首先调用了父类的onStartup，之后调用registerDispatcherServlet办法。父类的onStartup办法是实现rootApplicationContext调用的，至于什么是rootApplicationContext咱们临时不论，咱们先看一下registerDispatcherServlet办法：

protected void registerDispatcherServlet(ServletContext servletContext) {        String servletName = getServletName();        Assert.hasLength(servletName, "getServletName() must not return null or empty");        WebApplicationContext servletAppContext = createServletApplicationContext();        Assert.notNull(servletAppContext, "createServletApplicationContext() must not return null");        FrameworkServlet dispatcherServlet = createDispatcherServlet(servletAppContext);        Assert.notNull(dispatcherServlet, "createDispatcherServlet(WebApplicationContext) must not return null");        dispatcherServlet.setContextInitializers(getServletApplicationContextInitializers());   ...省略代码

首先调用createServletApplicationContext创立ServletApplicationContext（Servlet容器）,之后创立DispathcerServlet并且把创立好的Servlet容器传递给DispatcherServlet（DispatcherServlet要记录他所在的ServletApplicationContext）。

要害代码呈现了，Servlet容器的创立过程应该就在这个createServletApplicationContext办法中，是在AbstractAnnotationConfigDispatcherServletInitializer中实现的：

    @Override    protected WebApplicationContext createServletApplicationContext() {        AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext();        Class<?>[] configClasses = getServletConfigClasses();        if (!ObjectUtils.isEmpty(configClasses)) {            context.register(configClasses);        }        return context;    }

创立了一个新的AnnotationConfigWebApplicationContext对象，而后调用getServletConfigClasses()办法获取配置类，之后把配置类注册到了新创建的AnnotationConfigWebApplicationContext对象中。这个getServletConfigClasses()办法是没有实现的（应该是咱们的实现类须要实现的）。

至此，Spring通过Servlet3.0标准进行初始化的过程应该曾经很清晰了：
1.Spring Framework通过WebApplicationInitializer接口的onStartup办法实现Servlet上下文的初始化。
2.Spring Framework曾经实现了WebApplicationInitializer接口的大部分实现（提供了3个抽象类），曾经通过模板办法实现了大部分的初始化操作。
3. 猜想：应用层只须要扩大AbstractAnnotationConfigDispatcherServletInitializer类实现getServletConfigClasses()办法、返回Servlet的配置类，即可实现初始化。

接下来咱们就验证一下上述猜想。

创立基于注解的Spring MVC利用

依照上述猜想，咱们只须要扩大AbstractAnnotationConfigDispatcherServletInitializer、实现getServletConfigClasses()办法即可。

咱们还是用上篇文章中用过的例子来验证，在入手之前，因为注解形式和web.xml配置形式是抵触的（配置形式会笼罩掉注解形式），所以咱们须要删掉web.xml文件（copy进来即可）。

创立一个configuration包，并创立配置类（只有配置Controller的扫描门路即可）：

package org.example.configuration;import org.springframework.context.annotation.ComponentScan;import org.springframework.context.annotation.Configuration;@Configuration@ComponentScan("org.example.controller")public class MvcConfiguration {}

而后再创立initializer的实现类：

package org.example.configuration;import org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer;public class MvcInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {    @Override    protected Class<?>[] getRootConfigClasses() {        return new Class[0];    }    @Override    protected Class<?>[] getServletConfigClasses() {        return new Class[] {MvcConfiguration.class};    }    @Override    protected String[] getServletMappings() {        return new String[] {"/"};    }}

其中RootConfigClasse()办法是为RootApplicationContext服务的，咱们后面说过了，展现不论这个RootApplicationContext是什么，当初仍然也不论他。

getServletConfigClasses办法，返回咱们创立的初始化类。

还有一个getServletMappings办法，下面没有提到过，其实是起到web.xml中的servlet-mapping配置的作用的，所以咱们间接返回"/" - 默认匹配规定。

启动我的项目，拜访：

功败垂成！

上一篇 Spring MVC 二 ：基于xml配置