The Servlet specification defines an API standard, and the implementation of this standard is usually called a servlet container, such as the open source Tomcat and JBoss. A web container is more accurately called a web server, which is used to manage and deploy web applications. There is also a server called an application server, which is much more powerful than a web server because it can deploy EJB applications and implement container-managed transactions. General application servers include weblogic and websphere, etc., which are all commercial servers. Powerful but all for a fee. The most typical web container is tomcat, and Tomcat is a web container and a servlet container. The so-called container (server, middleware, etc.) is to provide some low-level, business-independent basic functions to provide services for the real Servlet. Simply put: the container is responsible for finding the corresponding servlet according to the requested information, passing the Request and Response parameters, calling the service method of the servlet, and completing the request response.
Understand ServletContext:
The javaee standard stipulates that the servlet container needs to initialize a ServletContext for the application project as a public environment container to store public information when the application project is started. The information in the ServletContext is provided by the container. Usually it is to configure web.xml, and its execution flow is:
web.xml declares application-wide initialization parameters in <context-param></context-param> tags
1. When starting a WEB project, the container (such as: Tomcat) will read its configuration file web.xml. Read two nodes: <listener></listener> and <context-param></context-param>
2. Next, the container creates a ServletContext (context). Shared globally within the app.
3. The container converts <context-param></context-param> into key-value pairs and hands them over to ServletContext.
4. The container creates a class instance in <listener></listener>, that is, creates a listener. The listener must implement the ServletContextListener interface
5. There will be a contextInitialized(ServletContextEvent event) initialization method in the monitoring. In this method, ServletContext = ServletContextEvent.getServletContext();
"context-param value" = ServletContext.getInitParameter("context-param key");
6. After getting the value of this context-param, you can do some operations. Note that your WEB project has not been fully started at this time. This action will be earlier than all Servlets. In other words, this time , the operation you do to the key value in <context-param> will be executed before your WEB project is fully started.
Two kinds of parameters can be defined in web.xml:
One is a global parameter (ServletContext), via <context-param></context-param>
One is the servlet parameter, by declaring <init-param> in the servlet
<param-name>param1</param-name>
<param-value>avalible in servlet init()</param-value>
</init-param>
The first parameter in the servlet can be obtained through getServletContext().getInitParameter("context/param")
The second parameter can only be obtained through this.getInitParameter("param1") in the init() method of the servlet
For spring configuration:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
1. The servlet container starts and creates a "global context" for the application: ServletContext
2. The container calls the ContextLoaderListener configured in web.xml, initializes the WebApplicationContext context (ie the IOC container), and loads the configuration file information specified by context-param into the IOC container.
WebApplicationContext is saved as key-value pair in ServletContext
3. The container initializes the servlet configured in web.xml, initializes its own context information servletContext for it, and loads the configuration information set by it into the context. Set WebApplicationContext as its parent container.
4、此后的所有servlet的初始化都按照3步中方式创建，初始化自己的上下文环境，将WebApplicationContext设置为自己的父上下文环境。
当Spring在执行ApplicationContext的getBean时，如果在自己context中找不到对应的bean，则会在父ApplicationContext中去找。这也解释了为什么我们可以在DispatcherServlet中获取到由ContextLoaderListener对应的ApplicationContext中的bean。
理解spring配置：
spring配置时：<context:exclude-filter>的使用原因，为什么在applicationContext.xml中排除controller，而在spring-mvc.xml中incloud这个controller
既然知道了spring的启动流程，那么web容器初始化webApplicationContext时作为公共的上下文环境，只需要将service、dao等的配置信息在这里加载，而servlet自己的上下文环境信息不需要加载。故，在applicationContext.xml中将@Controller注释的组件排除在外，而在dispatcherServlet加载的配置文件中将@Controller注释的组件加载进来，方便dispatcherServlet进行控制和查找。故，配置如下：
applicationContext.mxl中：
<context:component-scan base-package="com.common">
<context:exclude-filter expression="org.springframework.stereotype.Controller" type="annotation" />
</context:component-scan>
spring-mvc.xml中：
<context:component-scan base-package="com.common" use-default-filters="false">
<context:include-filter expression="org.springframework.stereotype.Controller" type="annotation" />
</context:component-scan>