1. What is Servlet?
Servlet is a server-side component specification formulated by Sun Corporation. It specifies not only the characteristics of being a servlet component, but also the characteristics that a system running Serlvet (called a servlet container) should have. The servlet component runs under the servlet container, and the servlet container is responsible for tasks such as "instantiating and managing servlet objects", "calling servlet life cycle methods", and "parsing and encapsulating requests and responses of specific protocols". A servlet class should implement the javax.servlet.Servlet interface and implement its lifecycle methods. The main one is public void service(ServletRequest request, ServletResponse response) throws ServletException, IOException { ... ... ... }
This method is called when the container receives a request. In the face of a large number of user visits, the servlet container generally manages servlets in a "single-instance, multi-thread" way, that is, the servlet container will only create one servlet instance, and different threads will be opened to run service methods for different user accesses. The servlet container generally A thread pool is maintained to manage these threads. In view of this management method of the servlet container, thread safety should be paid attention to for the service method. Generally, Servlet based on HTTP protocol is often used in practice. As a Servlet based on HTTP protocol, it can be obtained by inheriting javax.servlet.HttpServlet. The HttpServlet class implements the Servlet interface, and calls the corresponding method (doGet or doPost) in the service method according to different requests (get or post, etc.). In general, as a subclass of HttpServlet, it can override its doGet method to handle Get requests, and its doPost method to handle Post requests. In addition, HttpServlet can rewrite the init() and destroy() methods. The init() method is used to define the initialization logic, which will be called as soon as the Servlet is created. The destroy() method will be called before the servlet instance is destroyed. An HttpServlet needs to have a specific deployment descriptor (web.xml, placed in the application's /WEB-INF) to specify its characteristics: its definition is as follows:
<servlet> <servlet-name>Tst</servlet-name> <servlet-class>test.TestServlet</servlet-class> <init-param> <param-name>someKey</param-name> <param-value >someValue</param-value> </init-param> <load-on-startup>0</load-on-startup> </servlet> <servlet-mapping> <servlet-name>Tst</servlet-name > The <url-pattern>/test</url-pattern> </servlet-mapping> sub-element specifies the name of Serlvet as the unique identifier of the servlet. The child element is used to specify the class name of the servlet. The sub-element of is used to define the so-called initialization parameters based on key-value pairs. The Servlet object can obtain the corresponding value of the specified key by calling getInitParameter(String name) of the ServletConfig object. There can be multiple elements, which are used to define some initialization information that the servlet needs to obtain when working (such as: the path of some property files to be read, etc.). The sub-element of is used to specify whether to create the servlet object when the servlet container starts, or to instantiate the servlet object after the Serlvet container receives a request for the servlet. The latter strategy is adopted when the value of is negative, and the former strategy is adopted when the value of is 0 or positive. web. Multiple positive servlets may be defined in xml, and the servlet container will determine the order of instantiation according to the value of the servlet. Smaller values will be instantiated first, and larger values will be instantiated later. The element is used to map a specific servlet to a URI address. When the servlet container receives a request for the address, it will instantiate the corresponding servlet object and call its specific method. For example, if the url-pattern of a servlet is "/test", when you enter ".../application name/test" in the address bar of the browser, the servlet container will access the servlet. As a Tomcat server, you can also access servlets in other ways. There is also a web.xml in the conf subdirectory of its installation directory. Some servlets are defined in the web.xml. These servlets belong to Tomcat's built-in servlets. These servlet objects are instantiated at startup. The configuration information of InvokerServlet is as follows:
<servlet> <servlet-name>invoker</servlet-name> <servlet-class> org.apache.catalina.servlets.InvokerServlet </servlet-class> <init-param> <param-name>debug</param- name> <param-value>0</param-value> </init-param> <load-on-startup>2</load-on-startup> </servlet> <servlet-mapping> <servlet-name> invoker</servlet-name> <url-pattern>/servlet/*</url-pattern> </servlet-mapping> This servlet is used to access other servlets, and its default url-pattern configuration is /servlet/*. When we enter ".../servlet/class name of other servlets" in the address bar of the browser, the Tomcat container will access the servlet through InvokerServlet (even if the servlet is not defined in web.xml) For example: in the browser When you enter ".../application name/servlet/servet.TestServlet in the address bar, the servlet container will respond to test. TestServlet to access. This access method will facilitate the testing of the servlet. We can pay attention to another built-in servlet of Tomcat: DefaultServlet can be used to list the contents of a directory under the application. The configuration information of the servlet is as follows: <servlet> <servlet-name>default</servlet-name> <servlet-class >org.apache.catalina.servlets.DefaultServlet</servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param > <init-param> <param-name>listings</param-name> <param-value>true</param-value> </init-param> <load-on-startup>1</load-on- startup> </servlet> When the value of the initialization parameter named listings to change its configuration information is true, when the directory of an application is entered, DefaultServlet can list the contents of the directory as shown in the figure below and realize link navigation. Such a function will be helpful for testing. When the value of the initialization parameter named listings to change its configuration information is true, when the directory of an application is entered, DefaultServlet can list the contents of the directory and realize link navigation as shown in the figure below. Such a function will be helpful for testing.
Second, what is JSP? To be precise, JSP is a servlet. JSP is a standard text file. When it is accessed for the first time, the servlet will "translate" the file into a servlet, and then implement the call. Different application servers will have different translation methods. For the Tomcat server, we can pay attention to another built-in servlet defined in conf/web.xml: JspServlet. The function of this servlet is to "translate" JSP and implement access to it. The definition of the servlet is as follows: <servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> <init-param> <param-name>fork</param-name> < param-value>false</param-value> </init-param> <init-param> <param-name>xpoweredBy</param-name> <param-value>false</param-value> </init- param> <load-on-startup>3</load-on-startup> </servlet> <servlet-mapping> <servlet-name>jsp< /servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping> Note that the url-pattern of the servlet is "*.jsp" and all requests with the suffix ".jsp" will be Access the servlet, for example: enter ".../application name/test.jsp" in the browser address bar to access the servlet and the servlet will first obtain the content of the file named test.jsp, compile it into and implement the call. You can do a small experiment, replace the url-pattern corresponding to JspServlet in conf/web.xml (for example: change to hey), restart the Tomcat server, and access hello.jsp with the following content (the address is ".../ application name/hello.jsp") <html> <head> <title>hello.jsp</title> </head> <body> <% for (int i = 0; i <= 100; i++) { out. println("helloworld"); } %> </body> </html> By "right-clicking -> view source file" in the browser, you can see that the content you receive in the browser is: <html> <head> <title>hello.jsp</title> </head> <body> < % for (int i = 0; i <= 100; i++) { out.println("helloworld"); } %> </body> </html> It can be seen that the jsp is not parsed, but static text output as is. The "translated" Java source files and compiled class files of JSP can be found under \work\Catalina in the Tomcat installation directory. For the above hello.jsp, the "translated" Servlet source file is: \work\ Catalina\localhost\tst\org\apache\jsp\hello_jsp.java The main content of the file is as follows: package org.apache.jsp; import javax.servlet.*; import javax.servlet.http.*; import javax.servlet. jsp.*; public final class hello_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent { ... ... ... public void _jspService (HttpServletRequest request, HttpServletResponse response) throws java .io.IOException, ServletException { JspFactory _jspxFactory = null; PageContext pageContext = null; } } It can be seen that the "translated" class of hell.jsp is called hello_jsp, which inherits the org.apache.jasper.runtime.HttpJspBase class, which is a subclass of HttpServlet. HttpJspBase calls the _jspService method in its service method. For a specific jsp page, Tomcat's JSP engine "translates" it into a subclass of HttpJspBase and rewrites its _jspService method. Much of the initialization of this class is done by the JSP engine. In the above _jspService method, you can see the "shadow" of hello.jsp. The Java code written in JSP using <%...%> is placed in the _jspService method as it is; in addition, the HTML in JSP The script is output as it is through the stream object out... Of course, the "translation" of JSP cannot be so simple, because the JSP page may also have complex structures such as instructions and tags written. From the above _jspService method, it can also be seen that the so-called JSP built-in objects (request, response, application, session, etc.) are not mysterious. They are either the parameter variables of the _jspService method, or the JSP engine in the _jspService method. The pre-defined variables in JSP can be used directly in <%...%> of JSP The written Java code is placed in the _jspService method as it is; in addition, the HTML script in the JSP is output as it is through the stream object out... Of course, the "translation" of the JSP cannot be so simple, because the JSP page may also be written with complex structures such as directives, labels, etc. From the above _jspService method, it can also be seen that the so-called JSP built-in objects (request, response, application, session, etc.) are not mysterious. They are either the parameter variables of the _jspService method, or the JSP engine in the _jspService method. The pre-defined variables in JSP can be used directly in <%...%> of JSP The written Java code is placed in the _jspService method as it is; in addition, the HTML script in the JSP is output as it is through the stream object out... Of course, the "translation" of the JSP cannot be so simple, because the JSP page may also be written with complex structures such as directives, labels, etc. From the above _jspService method, it can also be seen that the so-called JSP built-in objects (request, response, application, session, etc.) are not mysterious. They are either the parameter variables of the _jspService method, or the JSP engine in the _jspService method. The pre-defined variables in JSP can be used directly in <%...%> of JSP