在基於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級的信息。