Listener, filter, servlet load order __spring and some Web concepts in Web.xml

Much of the information in the Web project is configured in the Web.xml file, and when the project starts, the container (for example, Tomcat) reads the configuration file first, so much of the content in the Web.xml file is loaded in what order.

This reading order is basically not related to the context order of the contents of the file, which means that the reading order of the configuration information is certain, and it does not matter where he is written, but the last possible first execution.

Analysis:

(1) because either listener,filter,servlet may use the contents of ServletContext in initialization, and this content comes from <context-param></context-param > Configuration.

So first read the <context-param></context-param> and <listener></listener> when you start the Web project

The location of <context-param></context-param> can be written casually, but it was first loaded.

After you get the value of this context-param, you can do something else, this time the Web project has not fully started, read Context-param is the earliest operation, than all the servlet and so on.

(2) Then Tomcat creates a ServletContext object, and the entire application of the Web project will share the Servletcontext,tomcat and then <context-param></ Context-param> into a key-value pair and handed to ServletContext.

(3) Tomcat creates a class instance in <listener></listener>, that is, creates a listener.

(4) There will be a contextinitialized (Servletcontextevent args) initialization method in the listener, in which the values in ServletContext can be obtained:

ServletContext = Servletcontextevent.getservletcontext ()

Context-param value = Servletcontext.getinitparameter ("Context-param key")

(5) Then is the filter and servlet

So the approximate order is: Context-param-> listener-> filter-> servlet

For a class of configuration sections, they are related to the order in which they appear.

Take filter For example, Web.xml can define multiple filter, of course, a configuration section related to filter is filter-mapping, it must be noted here, for the same filter-name filter and Filter-mappin In the case of the G configuration section, the filter-mapping must appear after the filter, otherwise, when parsing to filter-mapping, its corresponding filter-name is undefined. When each filter is initialized at web Tomcat startup, it is initialized according to the order in which the Filter configuration section appears, and when the request resource matches multiple filter-mapping, the filter interception resource is based on the filter-mapping The order in which the configuration section appears is called in turn to the Dofilter () method.

The mapping of the servlet is similar to filter.

About the Load-on-startup of the servlet:

The Load-on-startup element specifies the order in which the servlet is loaded when the Web application is started, and its value must be an integer. If its value is a negative integer or the element does not exist, Tomcat loads the servlet when the servlet is invoked. If the value is a positive integer or 0, tomcat loads and initializes the configuration when it is loaded servlet,tomcat must ensure that the value of the small is loaded first. If the values are equal, Tomcat can automatically choose who to load first.

The meaning of,<load-on-startup>0</load-on-startup> in the servlet configuration is:

(1) Mark whether Tomcat loads this servlet at boot time.

(2) A value of 0 or greater than 0 o'clock indicates that Tomcat loads the servlet when the application is started;

(3) When a negative number is not specified, it indicates that Tomcat is loaded when the servlet is selected.

(4) The smaller the value of a positive number, the higher the priority of starting the servlet.

Final conclusion:

The loading order of the Web.xml is: [Context-param-> listener-> filter-> servlet-> Spring], and the order of the actual program calls between the nodes of the same type is based on the corresponding Mappin The Order of G is invoked.

Web.xml Common Elements     <web-app>    <display-name></display-name> defines the name of the Web application     <description></description>  declaring Web Application description information       <context-param></ The Context-param> context-param element declares the initialization parameters within the scope of the application. The     <filter></filter>  filter element associates a name with a class that implements the Javax.servlet.Filter interface.     <filter-mapping></filter-mapping>  Once a filter has been named, You need to use the filter-mapping element to associate it with one or more servlet or JSP pages. The     &LT;LISTENER&GT;&LT;/LISTENER&GT;SERVLET&NBSP;API version 2.3 adds support for event listeners, and event listeners are building, Notified when modifying and deleting a session or servlet environment.                      The      listener element indicates an event listener class.     <servlet></servlet>  When you make initialization parameters or custom URLs to a servlet or JSP page, you must first name the servlet or JSP page. The servlet element is used to accomplish this task.     <servlet-mapping></servlet-mapping>  servers typically provide a default url:http://host/webapppre for the servletFix/servlet/servletname.                    However, this URL is often changed, So that the servlet can access the initialization parameters or more easily handle relative URLs. The servlet-mapping element is used when changing the default URL.       <session-config></session-config>  If a session is not accessed for a certain period of time, the server can discard it to save memory.                You can explicitly set a time-out value for a single Session object by using the HttpSession Setmaxinactiveinterval method, or you can use the Session-config element to set a default time-out.       <mime-mapping></mime-mapping> If Web applications have thought of special files, they want to be sure to assign them a specific MIME type. The mime-mapping element provides this assurance.     <welcome-file-list></welcome-file-list>  instructs the server to use which file when it receives a URL that references a directory name instead of a filename.     <error-page></error-page>  when a particular HTTP status code is returned, or when a particular type of exception is thrown, the page to be displayed will be made.     <taglib></taglib>  Specifies the alias for the tag Library descriptor file (tag libraryu descriptor file). This feature enables you to change the location of the TLD file,                       instead of editing JSP pages that use these files.     <resource-env-ref></resource-env-ref> declares a resource-related management object.     <resource-ref></resource-ref>  declares an external resource used by a resource factory.     <security-constraint></security-constraint>  develop URLs that should be protected. It is used in conjunction with the Login-config element