The servlet specification defines an API standard that is typically implemented as a servlet container, such as open source Tomcat and JBoss. The web container should be called a Web server more accurately, it is to manage and deploy the Web application. There is also a server called the application server, it is more powerful than the Web server, because it can deploy EJB applications, can implement container-managed transactions, the general application server has WebLogic and WebSphere, and so on, they are commercial servers, powerful but are charged. 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 of the underlying, business-related basic functions, for the real servlet to provide services. In a nutshell: The container is responsible for finding the corresponding servlet based on the requested information, passing the request and response parameters, invoking the Servlet's service method, and completing the requested response.
Understanding ServletContext:
The Java EE standard stipulates that the servlet container needs to initialize a servletcontext 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. Typically, the Web.xml is configured with the following process:
Web.xml declare the application-scoped initialization parameters in the <context-param></context-param> tab
1. When you start a Web project, the container (for example, Tomcat) reads its profile web.xml. Read two nodes: <listener></listener> and <context-param></ Context-param> 2. Immediately thereafter, the container creates a ServletContext (context). Globally shared within the application.
3. The container converts <context-param></context-param> into a key-value pair and is handed to ServletContext. 4. The class instance in the container creation <listener></listener>, that is, to create the listener. The listener must implement a Servletcontextlistener interface
5. There will be a contextinitialized (Servletcontextevent event) initialization method in the listener to obtain ServletContext in this method Servletcontextevent.getservletcontext ();
"Context-param Value" = Servletcontext.getinitparameter ("Context-param key"); 6. After you get the value of this context-param, you can do something about it. Note that this time your Web project is not fully started. This action will be earlier than all the servlet. In other words, this time, you are <context-param The key value in > will be executed before your Web project is fully launched. Web.xml can be defined in two parameters: One is a global parameter (ServletContext), through <context-param></context-param> One is a servlet parameter, by declaring in Servlet <init-param> &N Bsp <param-name>param1</param-name> & nbsp &NB Sp <param- Value>avalible in Servlet init () </param-value> &NB Sp &NB Sp </init-param> The first parameter can be passed through Getservletcontext () in the servlet. Getinitparameter ("Context/param") get The second parameter can only be passed through This.getinitparameter in the servlet's init () method ("param1" ) obtain
For the spring configuration:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
1, the servlet container starts, creates a "global context environment" for the application: ServletContext 2, The container invokes the Contextloaderlistener configured in Web.xml, initializes the Webapplicationcontext context (that is, the IOC container), loads the Context-param-specified profile information into the IOC container. Webapplicationcontext is saved in ServletContext as a key-value pair, 3, The container initializes the servlet configured in Web.xml, initializes its own context information servletcontext, and loads the configuration information for its settings into the context. Sets the Webapplicationcontext to its parent container. 4. All subsequent servlet initialization is created in 3 steps, initializes its own context environment, and sets Webapplicationcontext to its own parent context environment. When spring executes ApplicationContext getbean, if the corresponding bean is not found in its context, it is found in the parent applicationcontext. This also explains why we can get the beans in the dispatcherservlet that correspond to the ApplicationContext in the Contextloaderlistener.
Understanding the Spring Configuration:
Why:<context:exclude-filter> is used when spring is configured, Why exclude controller in Applicationcontext.xml, and in Spring-mvc.xml Incloud this controller Now that you know the spring's startup process, When the Web container initializes the Webapplicationcontext as a public context, only the configuration information for the service, DAO, and so on is loaded here, and the servlet's own context information does not need to be loaded. Therefore, the components of the @controller annotation are excluded from the applicationcontext.xml, and the components of the @controller annotation are loaded in the Dispatcherservlet-loaded configuration file. Convenient dispatcherservlet for control and search. Therefore, the configuration is as follows: 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>