Tomcat源码分析（三）：ServletContext应⽤启动之配置解析
概述
这篇是接我上篇⽂章：，主要来分析⼀下tomcat启动时，创建和初始化应⽤的ServletContext的详细过程。
我们知道在servlet规范设计当中，每个应⽤在servlet容器中，如tomcat，是使⽤⼀个servletContext来代表的，即servletContext 包含了该应⽤的相关配置，如session配置信息，sercurity相关的authentication，constraints，过滤器filters，⽤来处理客户端http请求的servlet集合，以及与url的映射关系等。如果应⽤使⽤spring框架，还有需要配置spring对servlet容器的启动ContextLoaderListener，请求DispatchServlet等。
ServeltContext的配置信息，⼀般可以通过在l⽂件中配置，tomcat在加载应⽤的时候会查并解析l，将相关信息填充到ServeltContext中，⼀个典型的l配置如下：
出⾃：blog.csdn/u010796790/article/details/52098258
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0"xmlns="java.sun/xml/ns/javaee"
xsi="/2001/XMLSchema-instance"
schemaLocation="java.sun/xml/ns/javaee java.sun/xml/ns/javaee/web-app_3_0.xsd">
<!-- 在Spring框架中是如何解决从页⾯传来的字符串的编码问题的呢？
下⾯我们来看看Spring框架给我们提供过滤器CharacterEncodingFilter
这个过滤器就是针对于每次浏览器请求进⾏过滤的，
然后再其之上添加了⽗类没有的功能即处理字符编码。
其中encoding⽤来设置编码格式，forceEncoding⽤来设置是否理会 CharacterEncoding()⽅法，设置为true则强制覆盖之前的编码格式。--> <filter>
<filter-name>characterEncodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>characterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<!-- 项⽬中使⽤Spring 时，l配置⽂件中并没有BeanFactory，
要想在业务层中的class ⽂件中直接引⽤Spring容器管理的bean可通过以下⽅式-->
<!--1、在l配置ContextLoaderListener-->
<!--ContextLoaderListener的作⽤就是启动Web容器时，
⾃动装配ApplicationContext的配置信息。
因为它实现了ServletContextListener这个接⼝，
在l配置这个，启动容器时，就会默认执⾏它实现的⽅法。
在ContextLoaderListener中关联了ContextLoader这个类，
所以整个加载配置过程由ContextLoader来完成。
它的API说明
第⼀段说明ContextLoader可以由 ContextLoaderListener和ContextLoaderServlet⽣成。
如果查看ContextLoaderServlet的API，
可以看到它也关联了ContextLoader这个类⽽且它实现了HttpServlet这个接⼝
第⼆段，ContextLoader创建的是 XmlWebApplicationContext这样⼀个类，
它实现的接⼝是WebApplicationContext->ConfigurableWebApplicationContext->ApplicationContext->
BeanFactory这样⼀来spring中的所有bean都由这个类来创建
IUploaddatafileManager uploadmanager = (IUploaddatafileManager) CurrentWebApplicationContext().getBean("uploadMa nager");
-->
<listener>
<listener-class>org.t.ContextLoaderListener</listener-class>
</listener>
<!--2、部署applicationContext的xml⽂件-->
<!--如果在l中不写任何参数配置信息，默认的路径是"/l，
在WEB-INF⽬录下创建的xml⽂件的名称必须是l。
如果是要⾃定义⽂件名可以在l⾥加⼊contextConfigLocation这个context参数：
在<param-value> </param-value>⾥指定相应的xml⽂件名，如果有多个xml⽂件，
可以写在⼀起并以“,”号分隔。
也可以这样applicationContext-*.xml采⽤通配符，
⽐如这那个⽬录下有l，
都会⼀同被载⼊。在ContextLoaderListener中关联了ContextLoader这个类，
所以整个加载配置过程由ContextLoader来完成。-->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:l</param-value>
</context-param>
<!--使⽤Spring MVC，配置DispatcherServlet是第⼀步。DispatcherServlet是⼀个Servlet,，所以可以配置多个DispatcherServlet-->
<!--DispatcherServlet是前置控制器，配置在l⽂件中的。拦截匹配的请求，Servlet拦截匹配规则要⾃已定义，把拦截下来的请求，依据某某规则分发到⽬标Controller(我们写的Action)来处理。-->
<servlet>
<servlet-name>DispatcherServlet</servlet-name>
<!--在DispatcherServlet的初始化过程中，框架会在web应⽤的 WEB-INF⽂件夹下寻名为[servlet-name]-l 的配置⽂件，⽣成⽂件中定义的bean。-->
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<!--指明了配置⽂件的⽂件名，不使⽤默认配置⽂件名，⽽使⽤l配置⽂件。-->
<init-param>
<param-name>contextConfigLocation</param-name>
<!--其中<param-value>**.xml</param-value> 这⾥可以使⽤多种写法-->
<!--1、不写，使⽤默认值:/WEB-INF/<servlet-name>-l-->
<!--2、<param-value>/WEB-INF/l</param-value>-->
<!--3、<param-value>classpath*:l</param-value>-->
<!--4、多个值⽤逗号分隔-->
<param-value>classpath:l</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
<!--是启动顺序，让这个Servlet随Servletp容器⼀起启动。-->
</servlet>
<servlet-mapping>
<!--这个Servlet的名字是dispatcher，可以有多个DispatcherServlet，是通过名字来区分的。每⼀个DispatcherServlet有⾃⼰的WebApplicationContext上下⽂对象。同时保存的ServletContext中和Request对象中.-->
<!--ApplicationContext是Spring的核⼼，Context我们通常解释为上下⽂环境，我想⽤“容器”来表述它更容易理解⼀些，ApplicationContext则是“应⽤的容器”了:P，Spring把Bean放在这个容器中，在需要的时候，⽤getBean⽅法取出-->
<servlet-name>DispatcherServlet</servlet-name>
<!--Servlet拦截匹配规则可以⾃已定义，当映射为@RequestMapping("/user/add")时，为例，拦截哪种URL合适？-->
<!--1、拦截*.do、*.htm，例如：/user/add.do，这是最传统的⽅式，最简单也最实⽤。不会导致静态⽂件（jpg,js,css）被拦截。-->
<!--2、拦截/，例如：/user/add，可以实现现在很流⾏的REST风格。很多互联⽹类型的应⽤很喜欢这种风格的URL。弊端：会导致静态⽂件（jpg,js,css）被拦截后不能正常显⽰。 -->
<url-pattern>/</url-pattern><!--会拦截URL中带“/”的请求。-->
</servlet-mapping>
<!--如果你的DispatcherServlet拦截"/"，为了实现REST风格，拦截了所有的请求，那么同时对*.js,*.jpg等静态⽂件的访问也就被拦截了。--> <!--⽅案⼀：激活Tomcat的defaultServlet来处理静态⽂件-->
<!--要写在DispatcherServlet的前⾯，让 defaultServlet先拦截请求，这样请求就不会进⼊Spring了，我想性能是最好的吧。-->
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.css</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.swf</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.gif</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.jpg</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.png</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.js</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.xml</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.json</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.map</url-pattern>
</servlet-mapping>
<welcome-file-list><!--指定欢迎页⾯-->
<welcome-file>login.html</welcome-file>
</welcome-file-list>
<error-page><!--当系统出现404错误，跳转到页⾯nopage.html-->
<error-code>404</error-code>
<location>/nopage.html</location>
</error-page>
<error-page><!--当系统出现java.lang.NullPointerException，跳转到页⾯error.html-->
<exception-type>java.lang.NullPointerException</exception-type>
<location>/error.html</location>
</error-page>
<session-config><!--会话超时配置，单位分钟-->
<session-timeout>360</session-timeout>
</session-config>
</web-app>
JavaConfig编程⽅式配置
在servlet 3.0及以上版本，除了可以通过l⽅式来配置，还可以通过基于Java类的⽅式来配置，即JavaConfig机制，从⽽省去l⽂件。具体为Servlet 3.0提供了⼀个ServletContainerInitializer接⼝来⽀持这种编程⽅式配置的实现，接⼝定义如下：
package javax.servlet;
import java.util.Set;
/**
* ServletContainerInitializers (SCIs) are registered via an entry in the
* file META-INF/services/javax.servlet.ServletContainerInitializer that must be
* included in the JAR file that contains the SCI implementation.
* <p>
* SCI processing is performed regardless of the setting of metadata-complete.
* SCI processing can be controlled per JAR file via fragment ordering. If an
* absolute ordering is defined, the only those JARs included in the ordering
* will be processed for SCIs. To disable SCI processing completely, an empty
* absolute ordering may be defined.
* <p>
* SCIs register an interest in annotations (class, method or field) and/or
* types via the {@link javax.servlet.annotation.HandlesTypes} annotation which
* is added to the class.
*
* @since Servlet 3.0
*/
public interface ServletContainerInitializer {
/
**
* Receives notification during startup of a web application of the classes
* within the web application that matched the criteria defined via the
* {@link javax.servlet.annotation.HandlesTypes} annotation.
*
* @param c The (possibly null) set of classes that met the specified
* criteria
* @param ctx The ServletContext of the web application in which the
* classes were discovered
*
* @throws ServletException If an error occurs
*/
void onStartup(Set<Class<?>> c, ServletContext ctx)throws ServletException;
}
1. ServletContainerInitializer接⼝的说明⼤概意思是说，ServletContainerInitializer接⼝的实现类需要实现SPI机制，即将
ServletContainerInitializer接⼝的实现类全限定名放到META-INF/services/javax.servlet.ServletContainerInitializer⽂件内，这样servlet容器启动的时候，在加载这个jar的时候，就会实例化META-INF/services/javax.servlet.ServletContainerInitializer列举的类。
2. @HandlesTypes：可以在ServletContainerInitializer接⼝实现类，加上@HandlesTypes，通过在@HandlesTypes注解中，包含
对ServeltContext，即应⽤启动感兴趣的接⼝，这样在应⽤启动过程中，则会通知到这些接⼝的实现类，这些接⼝实现类可以获取到ServletContext对象，从⽽可以调⽤ServletContext的⽅法对ServletContext填充数据，如addServlet⽅法来添加Spring的Dispatcher。
spring对ServletContainerInitializer的实现：主要是定义了⼀个WebApplicationInitializer接⼝。onStartup⽅法的
webAppInitializerClasses参数就是WebApplicationInitializer接⼝的实现类。
@HandlesTypes(WebApplicationInitializer.class)
public class SpringServletContainerInitializer implements ServletContainerInitializer {
@Override
public void onStartup(@Nullable Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
throws ServletException {
List<WebApplicationInitializer> initializers =new LinkedList<>();
if(webAppInitializerClasses != null){
// 排除接⼝或者抽象类，只处理具体的WebApplicationInitializer实现类
for(Class<?> waiClass : webAppInitializerClasses){
// Be defensive: Some servlet containers provide us with invalid classes,
// no matter what @
if(!waiClass.isInterface()&&!Modifier.Modifiers())&&
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");
// 排序
servlet和tomcat的关系AnnotationAwareOrderComparator.sort(initializers);
for(WebApplicationInitializer initializer : initializers){
// 将servletContext作为参数，调⽤WebApplicationInitializer实现类的onStartup⽅法
// 在onStartup⽅法中，定义具体的处理逻辑
}
}
}
典型⽤法：使⽤⼀个WebApplicationInitializer接⼝实现类替换l，如下添加了⼀个DispatchServlet，与上⾯在l中，通过servlet标签添加的⼀样。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论