Web containers and servlet



A web container is a service program that has a program on a server port that provides a service that handles requests from clients, such as the Tomcat container in Java, which is a container for ASP IIS or PWS. A server can have multiple containers.

Java is a dynamically loaded and run language. This means that when an application holds the address (CLASSPATH) and name (package name and class name) of a class, it can load the class at any time during the program run and create and use objects of that class. The servlet is based on this mechanism to merge with the Web container. All web containers that are currently known to support the Java servlet are developed using Java. When the Web container receives the request information from the client, it looks for the corresponding Servlet object in the servlet queue based on the Web Component address information in the URL, uses it directly if it is found, loads the corresponding class, and creates the object if it is not found. That is, the Servlet object was created the first time it was used, and once created, it is reused and no new objects are created. All created Servlet objects will be unified for garbage collection when the Web server stops running.

To address the problem of correspondence between the client request address and the Java servlet, the Web container requires a file that describes this correspondence, typically a web.xml file. If there are many Servlet in a Web application, then Web.xml will become very large. After the Servlet 3.0 specification is introduced, it allows Web.xml to slim down by allowing declarative syntax in the servlet code instead of the descriptive information in Web.xml. The following figure is a schematic diagram of this process.

In this diagram, we are simply a summary of the relationship between the Web container and the servlet in a more comprehensible way, and the processing process after accepting the request. In the actual web container, it's a lot more complicated than that.

Loading sequence of listener, filter and servlet in Web.xml and its detailed explanation
One
1. When starting a Web project, the Web container reads its profile web.xml, reads <listener> and <context-param> two nodes.
2. Urgently, create a ServletContext (servlet context), all parts of this Web project will share this context.
3. The container will convert <context-param> to the key value pair and give it to ServletContext.
4, the container creates the class instance in the <listener>, creates the listener.
Two
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, the container loads the servlet when the servlet is invoked. If the value is a positive integer or 0, the container loads and initializes the servlet when it is configured, and the container must ensure that the small value is loaded first. If the values are equal, the container can automatically choose who to load first.
The meaning of,<load-on-startup>5</load-on-startup> in the servlet configuration is:
Whether the tag container loads the servlet when it is started.
A value of 0 or greater than 0 o'clock indicates that the container loads the servlet when the application is started;
When a negative number is or is not specified, the container is indicated to be loaded when the servlet is selected.
The smaller the value of a positive number, the higher the priority of starting the servlet.
Three
The first thing to be sure is that the load order is independent of the order in which they are in the Web.xml file. The filter is not loaded first because the filter is written in front of the listener. The final conclusion is: Listener-> filter-> servlet
There is also a configuration section: Context-param, which is used to provide a key-value pair to ServletContext, the application context information. Our listener, filter, and so on are initialized with the information in these contexts, so the Context-param configuration section should be written in front of the Listener configuration section. In fact, the Context-param configuration section can be written anywhere, so the true loading 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-mappi In the case of NG configuration section, filter-mapping must appear after filter, otherwise, when parsing to filter-mapping, its corresponding filter-name is undefined. When each filter is initialized at the start of a web container, it is initialized in the order in which the Filter configuration section appears, and when the requested resource matches multiple filter-mapping, the filter interception resource is called sequentially in the order in which the Filter-mapping configuration section appears Dofilter () method.
The servlet is similar to filter, and is no longer being repeat here.
Thus, it can be seen that the loading order of the Web.xml is: Context-param-> listener-> filter-> servlet, and the order of the actual program calls between the same type is entered according to the corresponding mapping order Called by the row.