spring load order

Web.xml file loading sequence

1.
     1. When starting a WEB project, the WEB container will read its configuration file web.xml, and read the two nodes of <listener> and <context-param>.
     2. Urgently, create a ServletContext (servlet context), which will be shared by all parts of the web project.
     3. The container converts the <context-param> into a key-value pair and hands it to the servletContext.
     4. The container creates the class instance in <listener> and creates the listener.

2. The
      load-on-startup element specifies the order in which the servlets are loaded when the web application starts, and its value must be an integer. If its value is a negative integer or the element does not exist, the container will load the servlet when the servlet is called. If the value is a positive integer or zero, the container loads and initializes the servlet at configuration time. The container must ensure that the smaller value is loaded first. If the values ​​are equal, the container can automatically choose who to load first. In the servlet configuration, the meaning of <load-on-startup>5</load-on-startup> is: mark whether the container loads the servlet when it starts. When the value is 0 or greater than 0, it means that the container loads the servlet when the application starts; when it is a negative number or not specified, it means that the container loads the servlet when the servlet is selected. The smaller the positive value, the higher the priority of starting the servlet.

three,
      There are always some issues about loading priorities in the project, and I have encountered similar problems recently, so I have found the information and summarized it myself. Some of the following are reprinted by other people. The wheels are repeated, just a little bit of my own modification.
      The first thing to be sure is that the load order has nothing to do with their order in the web.xml file. That is, the filter will not be loaded first because the filter is written in front of the listener. The final conclusion is: listener -> filter -> servlet
also has such a configuration section: context-param , which is used to provide key-value pairs, that is, application context information, to ServletContext. Our listener, filter, etc. will use the information in these contexts during initialization, so should the context-param configuration section be written before the listener configuration section? Actually the context-param configuration section can be written anywhere, so the real loading order is: context-param -> listener -> filter -> servlet
      For certain types of configuration sections, the order in which they appear is relevant. Taking filter as an example, multiple filters can of course be defined in web.xml. A configuration section related to filter is filter-mapping. It must be noted here that for filter and filter-mapping configuration sections with the same filter-name, filter-mapping must appear after filter, otherwise when parsing to filter-mapping, its corresponding filter-name has not been defined. When each filter is initialized when the web container starts, it is initialized according to the order in which the filter configuration section appears. When the requested resource matches multiple filter-mappings, the filter interception resource is in accordance with the order in which the filter-mapping configuration section appears. DoFilter is called in turn () method.
      servlet is similar to filter, so I won't repeat it here.
      From this, it can be seen that the loading order of web.xml is: context-param -> listener -> filter -> servlet, and the order of actual program calls between the same type is based on the order of the corresponding mapping. called