在基于xml配置一个Spring-web-mvc项目时，Tomcat Localhost Log中打印出了一段info：
org.apache.catalina.core.ApplicationContext.log No Spring WebApplicationInitializer types detected on classpath
org.apache.catalina.core.ApplicationContext.log Initializing Spring root WebApplicationContext
org.apache.catalina.core.ApplicationContext.log Initializing Spring FrameworkServlet 'Dispatcher-Servlet'
尽管打印了这段info，项目确实启动起来了，而且各个功能模块也没有出问题，为什么第一行会打印出"No Spring WebApplicationInitializer types detected on classpath"呢？是不是我配置的哪里不对导致了Spring的初始化失败了？
在网上搜了一圈，回答的五花八门，但是没有一个是我目前的情况，带着这个问题，我在项目中查询了WebApplicationInitializer这个类：
/* * Copyright 2002-2012 the original author or authors. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package org.springframework.web; import javax.servlet.ServletContext; import javax.servlet.ServletException; /** * Interface to be implemented in Servlet 3.0+ environments in order to configure the * {@link ServletContext} programmatically -- as opposed to (or possibly in conjunction * with) the traditional {@code web.xml}-based approach. * * <p>Implementations of this SPI will be detected automatically by {@link * SpringServletContainerInitializer}, which itself is bootstrapped automatically * by any Servlet 3.0 container. See {@linkplain SpringServletContainerInitializer its * Javadoc} for details on this bootstrapping mechanism. * * <h2>Example</h2> * <h3>The traditional, XML-based approach</h3> * Most Spring users building a web application will need to register Spring's {@code * DispatcherServlet}. For reference, in WEB-INF/web.xml, this would typically be done as * follows: * <pre class="code"> * {@code * <servlet> * <servlet-name>dispatcher</servlet-name> * <servlet-class> * org.springframework.web.servlet.DispatcherServlet * </servlet-class> * <init-param> * <param-name>contextConfigLocation</param-name> * <param-value>/WEB-INF/spring/dispatcher-config.xml</param-value> * </init-param> * <load-on-startup>1</load-on-startup> * </servlet> * * <servlet-mapping> * <servlet-name>dispatcher</servlet-name> * <url-pattern>/</url-pattern> * </servlet-mapping>}</pre> * * <h3>The code-based approach with {@code WebApplicationInitializer}</h3> * Here is the equivalent {@code DispatcherServlet} registration logic, * {@code WebApplicationInitializer}-style: * <pre class="code"> * public class MyWebAppInitializer implements WebApplicationInitializer { * * @Override * public void onStartup(ServletContext container) { * XmlWebApplicationContext appContext = new XmlWebApplicationContext(); * appContext.setConfigLocation("/WEB-INF/spring/dispatcher-config.xml"); * * ServletRegistration.Dynamic dispatcher = * container.addServlet("dispatcher", new DispatcherServlet(appContext)); * dispatcher.setLoadOnStartup(1); * dispatcher.addMapping("/"); * } * * }</pre> * * As an alternative to the above, you can also extend from {@link * org.springframework.web.servlet.support.AbstractDispatcherServletInitializer}. * * As you can see, thanks to Servlet 3.0's new {@link ServletContext#addServlet} method * we're actually registering an <em>instance</em> of the {@code DispatcherServlet}, and * this means that the {@code DispatcherServlet} can now be treated like any other object * -- receiving constructor injection of its application context in this case. * * <p>This style is both simpler and more concise. There is no concern for dealing with * init-params, etc, just normal JavaBean-style properties and constructor arguments. You * are free to create and work with your Spring application contexts as necessary before * injecting them into the {@code DispatcherServlet}. * * <p>Most major Spring Web components have been updated to support this style of * registration. You'll find that {@code DispatcherServlet}, {@code FrameworkServlet}, * {@code ContextLoaderListener} and {@code DelegatingFilterProxy} all now support * constructor arguments. Even if a component (e.g. non-Spring, other third party) has not * been specifically updated for use within {@code WebApplicationInitializers}, they still * may be used in any case. The Servlet 3.0 {@code ServletContext} API allows for setting * init-params, context-params, etc programmatically. * * <h2>A 100% code-based approach to configuration</h2> * In the example above, {@code WEB-INF/web.xml} was successfully replaced with code in * the form of a {@code WebApplicationInitializer}, but the actual * {@code dispatcher-config.xml} Spring configuration remained XML-based. * {@code WebApplicationInitializer} is a perfect fit for use with Spring's code-based * {@code @Configuration} classes. See @{@link * org.springframework.context.annotation.Configuration Configuration} Javadoc for * complete details, but the following example demonstrates refactoring to use Spring's * {@link org.springframework.web.context.support.AnnotationConfigWebApplicationContext * AnnotationConfigWebApplicationContext} in lieu of {@code XmlWebApplicationContext}, and * user-defined {@code @Configuration} classes {@code AppConfig} and * {@code DispatcherConfig} instead of Spring XML files. This example also goes a bit * beyond those above to demonstrate typical configuration of the 'root' application * context and registration of the {@code ContextLoaderListener}: * <pre class="code"> * public class MyWebAppInitializer implements WebApplicationInitializer { * * @Override * public void onStartup(ServletContext container) { * // Create the 'root' Spring application context * AnnotationConfigWebApplicationContext rootContext = * new AnnotationConfigWebApplicationContext(); * rootContext.register(AppConfig.class); * * // Manage the lifecycle of the root application context * container.addListener(new ContextLoaderListener(rootContext)); * * // Create the dispatcher servlet's Spring application context * AnnotationConfigWebApplicationContext dispatcherContext = * new AnnotationConfigWebApplicationContext(); * dispatcherContext.register(DispatcherConfig.class); * * // Register and map the dispatcher servlet * ServletRegistration.Dynamic dispatcher = * container.addServlet("dispatcher", new DispatcherServlet(dispatcherContext)); * dispatcher.setLoadOnStartup(1); * dispatcher.addMapping("/"); * } * * }</pre> * * As an alternative to the above, you can also extend from {@link * org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer}. * * Remember that {@code WebApplicationInitializer} implementations are <em>detected * automatically</em> -- so you are free to package them within your application as you * see fit. * * <h2>Ordering {@code WebApplicationInitializer} execution</h2> * {@code WebApplicationInitializer} implementations may optionally be annotated at the * class level with Spring's @{@link org.springframework.core.annotation.Order Order} * annotation or may implement Spring's {@link org.springframework.core.Ordered Ordered} * interface. If so, the initializers will be ordered prior to invocation. This provides * a mechanism for users to ensure the order in which servlet container initialization * occurs. Use of this feature is expected to be rare, as typical applications will likely * centralize all container initialization within a single {@code WebApplicationInitializer}. * * <h2>Caveats</h2> * * <h3>web.xml versioning</h3> * <p>{@code WEB-INF/web.xml} and {@code WebApplicationInitializer} use are not mutually * exclusive; for example, web.xml can register one servlet, and a {@code * WebApplicationInitializer} can register another. An initializer can even * <em>modify</em> registrations performed in {@code web.xml} through methods such as * {@link ServletContext#getServletRegistration(String)}. <strong>However, if * {@code WEB-INF/web.xml} is present in the application, its {@code version} attribute * must be set to "3.0" or greater, otherwise {@code ServletContainerInitializer} * bootstrapping will be ignored by the servlet container.</strong> * * <h3>Mapping to '/' under Tomcat</h3> * <p>Apache Tomcat maps its internal {@code DefaultServlet} to "/", and on Tomcat versions * <= 7.0.14, this servlet mapping <em>cannot be overridden programmatically</em>. * 7.0.15 fixes this issue. Overriding the "/" servlet mapping has also been tested * successfully under GlassFish 3.1.<p> * * @author Chris Beams * @since 3.1 * @see SpringServletContainerInitializer * @see org.springframework.web.context.AbstractContextLoaderInitializer * @see org.springframework.web.servlet.support.AbstractDispatcherServletInitializer * @see org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer */ public interface WebApplicationInitializer { /** * Configure the given {@link ServletContext} with any servlets, filters, listeners * context-params and attributes necessary for initializing this web application. See * examples {@linkplain WebApplicationInitializer above}. * @param servletContext the {@code ServletContext} to initialize * @throws ServletException if any call against the given {@code ServletContext} * throws a {@code ServletException} */ void onStartup(ServletContext servletContext) throws ServletException; }
其内部的代码不多，但是有相当长的一段JavaDoc来对这个类进行说明。
简单的读一下WebApplicationInitializer类的JavaDoc第一段：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。
大概的意思是说：在Servlet 3.0以上的环境中可以通过实现该接口来以编程的方式来配置ServletContext。与之相对应的是基于web.xml的配置方式。
继续往下看WebApplicationInitializer类的JavaDoc第二段：Implementations of this SPI will be detected automatically by SpringServletContainerInitializer, which itself is bootstrapped automatically by any Servlet 3.0 container. See SpringServletContainerInitializer its Javadoc for details on this bootstrapping mechanism.
大概的意思是说：实现了这个接口的类会自动被SpringServletContainerInitializer检测到，可以看一下SpringServletContainerInitializer的JavaDoc来获得更多的详细信息。
那么就来看一下这个SpringServletContainerInitializer：
/* * Copyright 2002-2014 the original author or authors. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package org.springframework.web; import java.lang.reflect.Modifier; import java.util.LinkedList; import java.util.List; import java.util.ServiceLoader; import java.util.Set; import javax.servlet.ServletContainerInitializer; import javax.servlet.ServletContext; import javax.servlet.ServletException; import javax.servlet.annotation.HandlesTypes; import org.springframework.core.annotation.AnnotationAwareOrderComparator; /** * Servlet 3.0 {@link ServletContainerInitializer} designed to support code-based * configuration of the servlet container using Spring's {@link WebApplicationInitializer} * SPI as opposed to (or possibly in combination with) the traditional * {@code web.xml}-based approach. * * <h2>Mechanism of Operation</h2> * This class will be loaded and instantiated and have its {@link #onStartup} * method invoked by any Servlet 3.0-compliant container during container startup assuming * that the {@code spring-web} module JAR is present on the classpath. This occurs through * the JAR Services API {@link ServiceLoader#load(Class)} method detecting the * {@code spring-web} module's {@code META-INF/services/javax.servlet.ServletContainerInitializer} * service provider configuration file. See the * <a href="http://download.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Service%20Provider"> * JAR Services API documentation</a> as well as section <em>8.2.4</em> of the Servlet 3.0 * Final Draft specification for complete details. * * <h3>In combination with {@code web.xml}</h3> * A web application can choose to limit the amount of classpath scanning the Servlet * container does at startup either through the {@code metadata-complete} attribute in * {@code web.xml}, which controls scanning for Servlet annotations or through an * {@code <absolute-ordering>} element also in {@code web.xml}, which controls which * web fragments (i.e. jars) are allowed to perform a {@code ServletContainerInitializer} * scan. When using this feature, the {@link SpringServletContainerInitializer} * can be enabled by adding "spring_web" to the list of named web fragments in * {@code web.xml} as follows: * * <pre class="code"> * {@code * <absolute-ordering> * <name>some_web_fragment</name> * <name>spring_web</name> * </absolute-ordering> * }</pre> * * <h2>Relationship to Spring's {@code WebApplicationInitializer}</h2> * Spring's {@code WebApplicationInitializer} SPI consists of just one method: * {@link WebApplicationInitializer#onStartup(ServletContext)}. The signature is intentionally * quite similar to {@link ServletContainerInitializer#onStartup(Set, ServletContext)}: * simply put, {@code SpringServletContainerInitializer} is responsible for instantiating * and delegating the {@code ServletContext} to any user-defined * {@code WebApplicationInitializer} implementations. It is then the responsibility of * each {@code WebApplicationInitializer} to do the actual work of initializing the * {@code ServletContext}. The exact process of delegation is described in detail in the * {@link #onStartup onStartup} documentation below. * * <h2>General Notes</h2> * In general, this class should be viewed as <em>supporting infrastructure</em> for * the more important and user-facing {@code WebApplicationInitializer} SPI. Taking * advantage of this container initializer is also completely <em>optional</em>: while * it is true that this initializer will be loaded and invoked under all Servlet 3.0+ * runtimes, it remains the user's choice whether to make any * {@code WebApplicationInitializer} implementations available on the classpath. If no * {@code WebApplicationInitializer} types are detected, this container initializer will * have no effect. * * <p>Note that use of this container initializer and of {@code WebApplicationInitializer} * is not in any way "tied" to Spring MVC other than the fact that the types are shipped * in the {@code spring-web} module JAR. Rather, they can be considered general-purpose * in their ability to facilitate convenient code-based configuration of the * {@code ServletContext}. In other words, any servlet, listener, or filter may be * registered within a {@code WebApplicationInitializer}, not just Spring MVC-specific * components. * * <p>This class is neither designed for extension nor intended to be extended. * It should be considered an internal type, with {@code WebApplicationInitializer} * being the public-facing SPI. * * <h2>See Also</h2> * See {@link WebApplicationInitializer} Javadoc for examples and detailed usage * recommendations.<p> * * @author Chris Beams * @author Juergen Hoeller * @author Rossen Stoyanchev * @since 3.1 * @see #onStartup(Set, ServletContext) * @see WebApplicationInitializer */ @HandlesTypes(WebApplicationInitializer.class) public class SpringServletContainerInitializer implements ServletContainerInitializer { /** * Delegate the {@code ServletContext} to any {@link WebApplicationInitializer} * implementations present on the application classpath. * * <p>Because this class declares @{@code HandlesTypes(WebApplicationInitializer.class)}, * Servlet 3.0+ containers will automatically scan the classpath for implementations * of Spring's {@code WebApplicationInitializer} interface and provide the set of all * such types to the {@code webAppInitializerClasses} parameter of this method. * * <p>If no {@code WebApplicationInitializer} implementations are found on the * classpath, this method is effectively a no-op. An INFO-level log message will be * issued notifying the user that the {@code ServletContainerInitializer} has indeed * been invoked but that no {@code WebApplicationInitializer} implementations were * found. * * <p>Assuming that one or more {@code WebApplicationInitializer} types are detected, * they will be instantiated (and <em>sorted</em> if the @{@link * org.springframework.core.annotation.Order @Order} annotation is present or * the {@link org.springframework.core.Ordered Ordered} interface has been * implemented). Then the {@link WebApplicationInitializer#onStartup(ServletContext)} * method will be invoked on each instance, delegating the {@code ServletContext} such * that each instance may register and configure servlets such as Spring's * {@code DispatcherServlet}, listeners such as Spring's {@code ContextLoaderListener}, * or any other Servlet API componentry such as filters. * * @param webAppInitializerClasses all implementations of * {@link WebApplicationInitializer} found on the application classpath * @param servletContext the servlet context to be initialized * @see WebApplicationInitializer#onStartup(ServletContext) * @see AnnotationAwareOrderComparator */ @Override public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext) throws ServletException { List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>(); 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; } AnnotationAwareOrderComparator.sort(initializers); servletContext.log("Spring WebApplicationInitializers detected on classpath: " + initializers); for (WebApplicationInitializer initializer : initializers) { initializer.onStartup(servletContext); } } }
这次的代码要多一些了，实现了一个ServletContainerInitializer接口，Override了一个方法。
内容挺简单的，就是遍历一个Class集合，如果是WebApplicationInitializer的子类且不是接口或抽象类就实例化并放到一个新的集合中。
如果没有一个Class实例化成功的话，就会输出"No Spring WebApplicationInitializer types detected on classpath"，否则就挨个调用实例的onStartup方法。
原来我们看到的这句话是在这里打印出来的。
接下来我们再来看看WebApplicationInitializer类的JavaDoc第一段：
Servlet 3.0 ServletContainerInitializer designed to support code-based configuration of the servlet container using Spring's WebApplicationInitializer SPI as opposed to (or possibly in combination with) the traditional web.xml-based approach。
大概的意思是说：Servlet 3.0的ServletContainerInitializer是被设计来支持基于代码配置Servlet容器的。
还有onStartup方法的JavaDoc第二段:
Because this class declares @HandlesTypes(WebApplicationInitializer.class), Servlet 3.0+ containers will automatically scan the classpath for implementations of Spring's WebApplicationInitializer interface and provide the set of all such types to the webAppInitializerClasses parameter of this method.
大概的意思是说：可以使用@HadnlesTypes注解来注入某个类。这个类及其子类的class将被web容器自动扫描并传入webAppInitializerClasses这个参数上。
到了这里，情况就比较明朗了：
SpringWebApplication在启动时Web容器会创建一个ServletContext也就是俗称的上下文，这个上下文的初始化是基于web.xml来的。
Servlet 3.0之后开始支持基于JavaConfig的配置方式，会先扫描JavaConfig(也就是WebApplicationInitializer的实现类)，如果没有找到JavaConfig就输出"No Spring WebApplicationInitializer types detected on classpath"。找到了就调用其onStartup方法来初始化ServletContext。
但是这里还是有最根本的问题在：我根本就没有写过实现WebApplicationInitializer的类，为什么还会去加载呢？
带着这个疑问继续去看看这个ServletContainerInitializer接口：
/* * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER. * * Copyright (c) 2008-2013 Oracle and/or its affiliates. All rights reserved. * * The contents of this file are subject to the terms of either the GNU * General Public License Version 2 only ("GPL") or the Common Development * and Distribution License("CDDL") (collectively, the "License"). You * may not use this file except in compliance with the License. You can * obtain a copy of the License at * https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html * or packager/legal/LICENSE.txt. See the License for the specific * language governing permissions and limitations under the License. * * When distributing the software, include this License Header Notice in each * file and include the License file at packager/legal/LICENSE.txt. * * GPL Classpath Exception: * Oracle designates this particular file as subject to the "Classpath" * exception as provided by Oracle in the GPL Version 2 section of the License * file that accompanied this code. * * Modifications: * If applicable, add the following below the License Header, with the fields * enclosed by brackets [] replaced by your own identifying information: * "Portions Copyright [year] [name of copyright owner]" * * Contributor(s): * If you wish your version of this file to be governed by only the CDDL or * only the GPL Version 2, indicate your decision by adding "[Contributor] * elects to include this software in this distribution under the [CDDL or GPL * Version 2] license." If you don't indicate a single choice of license, a * recipient has the option to distribute your version of this file under * either the CDDL, the GPL Version 2 or to extend the choice of license to * its licensees as provided above. However, if you add GPL Version 2 code * and therefore, elected the GPL Version 2 license, then the option applies * only if the new code is made subject to such option by the copyright * holder. */ package javax.servlet; import java.util.Set; /** * Interface which allows a library/runtime to be notified of a web * application's startup phase and perform any required programmatic * registration of servlets, filters, and listeners in response to it. * * <p>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. * * <p>If an implementation of this interface does not use <tt>HandlesTypes</tt> * annotation, or none of the application classes match the ones specified * by the annotation, the container must pass a <tt>null</tt> Set of classes * to {@link #onStartup}. * * <p>When examining the classes of an application to see if they match * any of the criteria specified by the <tt>HandlesTypes</tt> annontation * of a <tt>ServletContainerInitializer</tt>, 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. * * <p>Implementations of this interface must be declared by a JAR file * resource located inside the <tt>META-INF/services</tt> 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, <tt>ServletContainerInitializer</tt> 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 { /** * Notifies this <tt>ServletContainerInitializer</tt> of the startup * of the application represented by the given <tt>ServletContext</tt>. * * <p>If this <tt>ServletContainerInitializer</tt> is bundled in a JAR * file inside the <tt>WEB-INF/lib</tt> directory of an application, * its <tt>onStartup</tt> method will be invoked only once during the * startup of the bundling application. If this * <tt>ServletContainerInitializer</tt> is bundled inside a JAR file * outside of any <tt>WEB-INF/lib</tt> directory, but still * discoverable as described above, its <tt>onStartup</tt> method * will be invoked every time an application is started. * * @param c the Set of application classes that extend, implement, or * have been annotated with the class types specified by the * {@link javax.servlet.annotation.HandlesTypes HandlesTypes} annotation, * or <tt>null</tt> if there are no matches, or this * <tt>ServletContainerInitializer</tt> has not been annotated with * <tt>HandlesTypes</tt> * * @param ctx the <tt>ServletContext</tt> of the web application that * is being started and in which the classes contained in <tt>c</tt> * were found * * @throws ServletException if an error has occurred */ public void onStartup(Set<Class<?>> c, ServletContext ctx) throws ServletException; }
在第五段的内容解答了我的疑问：
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.
Web容器在启动时会扫描所有ServletContainerInitializer的实现。
扫描的方法为在所有Jar包下查找路径为META-INF/services/javax.servlet.ServletContainerInitializer文件，根据文件内的全路径进行实例化。
然后我们回头看一下SpringServletContainerInitializer所在的包：
原来，Spring已经准备好了一个实现ServletContainerInitializer的类SpringServletContainerInitializer。并在其META-INF/services/javax.servlet.ServletContainerInitializer文件路径下写入了该类的限定名。
这样一来，Web容器在加载时第一时间就找到了这个类，然后调用了它的onStartup方法。
在这个方法内，@HandlesTypes注解注入了所有实现了WebApplicationInitializer接口的类的class，onStartup方法尝试对这些class进行实例化，如果实例化成功，就依次调用实例onStartup方法初始化ServletContext，如果没有一个实例化成功，就打印log然后让Web容器去读web.xml。
直到打印出这段log之前所有的行为都跟web.xml和Spring的配置无关，因为这个时候ServletContext还没完成初始化。而且这也不是错误，只是一个info级的信息。