Implementation principle of JSP hot deployment in tocmat

We know that the JSP file takes effect immediately when developing the project. Due to curiosity, we have studied Tomcat's implementation principles for JSP hot deployment. The implementation principle of Tomcat JSP hot deployment is generally like this. Each JSP page has a default cache time of several seconds from the last visit to the next visit, that is to say, the modification is not strictly effective, that is, tocmat7 has a cache delay of 4 seconds by default. The default cache latency is defined in the private intmodificationtestinterval = 4; Attribute of the class embeddedservletoptions. If the cache expires after 4 seconds, Tomcat will read the modified timestamp of JSP and compare it with the modified timestamp of the compiled class file in the work directory. If it is equal, the class file does not expire, and the JSP file will not be re-compiled. If it expires, the JSP will be re-compiled into Java and further compiled into class. At the same time, jasperloader is called to reload the class file compiled by JSP. The following is a detailed analysis of this process:

The general sequence of class communication is as follows:

 

The verification logic of the timestamp mentioned above is mainly encapsulated in the isoutdated method of jdtcompiler.Source codeAs follows:

 

The first red box is the involved N-second cache logic. If the cache does not expire, it will not be reloaded. This ctxt. getoptions () obtains the embeddedservletoptions class. The default interval of this class is:

 

During the experiment, I was curious and changed the value to 40. It was true that JSP did not take effect in time, but it took 40 seconds to take effect. The second red box detects the object of the class file under the Work directory. The third red box compares the timestamp of the class file with the timestamp of the JSP file. If not, recompile and load the file (the above sequence diagram process ). This is the hot deployment process of JSP!