Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "what are the knowledge points of Servlet specification and Servlet container". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

After the HTTP server receives the request, our Java class will deal with it. In order to prevent the HTTP server code from coupling with the business code, there is an interface-oriented servlet interface. Sometimes we call the business class that implements the Servlet interface Servlet. For a particular request, how does the HTTP server know which Servlet will handle it? Who instantiates Servlet? Obviously, the HTTP server is not suitable for this job, otherwise it will be coupled with the business class. The Servlet container is then used to load and manage business classes. The HTTP server does not deal directly with the business class, but hands the request to the Servlet container for processing. The Servlet container forwards the request to the specific Servlet. If the Servlet has not been created, it loads and instantiates the Servlet, and then calls the Servlet's interface method. So the Servlet interface is actually the interface between the Servlet container and the specific business class.

The service method in the Servlet interface, in which the specific business class implements the processing logic. This method has two parameters: ServletRequest and ServletResponse. ServletRequest is used to encapsulate request information, and ServletResponse is used to encapsulate response information, so these two classes are essentially encapsulation of communication protocols. For example, the request and response in the HTTP protocol correspond to the HttpServletRequest and HttpServletResponse classes. You can get all the information related to the request through HttpServletRequest, including the request path, Cookie, HTTP header, request parameters, etc. In addition, as I mentioned in the last column, we can also create and get Session through HttpServletRequest. HttpServletResponse is used to encapsulate HTTP responses. You can see that there are also two lifecycle-related methods init and destroy in the interface, which is an intimate design. The Servlet container calls the init method when loading the Servlet class and the destroy method when unloading. We may initialize some resources in the init method and release them in the destroy method, such as DispatcherServlet in Spring MVC, to create our own Spring container in the init method. You will also notice the class ServletConfig, where the function of ServletConfig is to encapsulate the initialization parameters of Servlet. You can configure parameters for Servlet in web.xml and get them in the program through the getServletConfig method. Where there is an interface, there are generally abstract classes, and abstract classes are used to implement interfaces and encapsulate general logic, so the Servlet specification provides GenericServlet abstract classes, and we can implement Servlet by extending it. Although the Servlet specification does not care what the communication protocol is, most Servlet is handled in the HTTP environment, so the Servet specification also provides HttpServlet to inherit GenericServlet and adds the HTTP feature. So we implement our own Servlet by inheriting the HttpServlet class, and only need to rewrite two methods: doGet and doPost.

Servlet container

When a customer requests a resource, the HTTP server encapsulates the customer's request information with a ServletRequest object, and then calls the service method of the Servlet container. After the Servlet container gets the request, it finds the corresponding Servlet according to the mapping relationship between the requested URL and Servlet. If the Servlet has not been loaded, it uses the reflection mechanism to create the Servlet, calls the init method of Servlet to complete the initialization, and then calls the service method of Servlet to process the request. The ServletResponse object is returned to the HTTP server, and the HTTP server sends the response to the client.

The ServletContext interface is defined in the Servlet specification to correspond to a Web application. After the Web application is deployed, the Servlet container loads the Web application at startup and creates a unique ServletContext object for each Web application. You can think of ServletContext as a global object. A Web application may have multiple Servlet. These Servlet can share data through the global ServletContext, including the initialization parameters of the Web application, the file resources under the Web application directory, and so on. Since ServletContext holds all Servlet instances, you can also use it to forward Servlet requests.

| |-MyWebApp |

| |-WEB-INF/web.xml-- configuration file, which is used to configure Servlet, etc. |

| |-WEB-INF/lib/-- stores various JAR packages required for Web applications |

| |-WEB-INF/classes/-- stores your application class, such as Servlet class |

| |-META-INF/-- the directory stores some information about the project |

The Servlet specification provides two extension mechanisms: Filter and Listener. Filter is a filter, and this interface allows you to customize requests and responses. For example, you can restrict access according to the frequency of the request, or modify the response content according to different countries and regions. The filter works like this: after the Web application is deployed, the Servlet container needs to instantiate the Filter and link the Filter into a FilterChain. When the request comes in, get the first Filter and call the doFilter method, which is responsible for calling the next Filter in this FilterChain. Listener is a listener, which is another extension mechanism. When the Web application runs in the Servlet container, various events continue to occur inside the Servlet container, such as the start and stop of the Web application, the arrival of user requests, and so on. The Servlet container provides some default listeners to listen to these events, and when the event occurs, the Servlet container is responsible for calling the listener's methods. Of course, you can define your own listener to listen for events of interest to you and configure the listener in web.xml. For example, Spring implements its own listener to listen for ServletContext startup events in order to create and initialize a global Spring container when the Servlet container starts. Filter interferes with the process, it is a part of the process, and is based on the process behavior. Listener is state-based. If any behavior changes the same state, the events triggered are consistent.

This is the end of the introduction of "what are the knowledge points of Servlet specification and Servlet container". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.