1. web.xml loading process:
1. When starting a WEB project, the WEB container will read its configuration file web.xml, and read <listener></listener> and <context-param></context-param>
2. The container creates a ServletContext (context), which will be shared by all parts of the WEB project.
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.
5. There will be a contextInitialized(ServletContextEvent args) initialization method in the listener, which is obtained in this method:
ServletContext = ServletContextEvent.getServletContext();
value of context-param = ServletContext.getInitParameter("key of context-param");
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, at this time, the operation you do to the key value in <context-param> will be executed before your WEB project is fully started.
7. Example: You may want to open the database before the project starts. Then here you can set the database connection method in <context-param>, and initialize the database connection in the listener class.
8. This listener is a class written by itself. In addition to the initialization method, it also has a destruction method. Used to release resources before closing the application. For example, closing the database connection.
web.xml node loading order: context -> param -> listener -> filter
二.load-on-startup
The load-on-startup element specifies the order in which 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 loads 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. It can be seen that 0 is loaded first, then 1, 2, 3, , , negative numbers
In the servlet configuration, the meaning of <load-on-startup>5</load-on-startup> is:
Marks whether the container should load this servlet at startup.
When the value is 0 or greater than 0, it means that the container loads the servlet when the application starts;
When a negative number or not specified, instructs the container to load only when the servlet is selected.
The smaller the positive value, the higher the priority of starting the servlet.
Three. web.xml node loading order
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 loading 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 listeners, filters, etc. will use the information in these contexts during initialization, so should the context-param configuration section be written before the listener configuration section? In fact, 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 related. 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 in the order in which the filter configuration section appears. When the requested resource matches multiple filter-mappings, the filter interception resource is in the order in which the filter-mapping configuration section appears. DoFilter is called in turn. () method.