Engineering Full Stack Apps with Java and JavaScript
JSPs are actually servlets, as you have already seen. Container will convert all jsp files into servlets before executing them. JSPs just provide an easy way to create components containing non-java code.
Once a JSP page is created and deployed, container will do some life cycle events, which also includes calling some of its methods similar to servlet life cycle events.
JSP page translation (validation, translation, compilation phases)
Load Class
Instantiate
jspInit method is called
_jspService method is called
jspDestroy method is called
Validation is performed before translation. Syntax checking happens and all references to tag libraries, actions and EL functions in the JSP are validated to ensure that they exist and are accessible to the page, and if there are any issues an error occurs and prevents the translation process from continuing.
Before validation, JSP page is converted to an XML view and this xml is view is then validated and translated.
Initial JSP input page is translated into servlet source code. While doing so, it will write the print statements for each of your non java lines in the JSP (please see previous demo). This generated servlet should implement HttpJspPage or its parent JspPage based on if the environment is HTTP based or not.
A vendor will typically have a specialized JSP base servlet, extending and implementing all required classes or interfaces. In Tomcat, this is called org.apache.jasper.runtime.HttpJspBase. HttpJspBase extends HttpServlet and GenericServlet, and implements HttpJspPage, JspPage, Serializable, Servlet, ServletConfig (please see previous demo).
Servlet source code is then compiled into a servlet class file.
Outputs
There are two outputs within the translation phase.
The first is an interim output: a Java source file for a servlet.
The second is the compiled class file from the servlet source.
The class file is retained for future use, and most JSP containers may retain or give you an option whereby you can retain the servlet source for debugging purposes.
In Tomcat, the generated servlet Java source and compiled class during JSP translation will, by default, be kept in which directory <Tomcat-Installation-Directory>/work/Catalina/localhost/<context- directory>/org/apache/jsp.
Timing
Even though a JSP container has discretion regarding when the translation occurs, by default (in most cases) the JSP is compiled into a servlet and then loaded the first time it is accessed.
This might cause a small delay for the first request, but there won’t be any delay in subsequent requests.
In certain application servers, you may also precompile JSPs before adding them into JARs.
Errors
If a page fails to translate, an HTTP request for the page should give rise to a 500 (server error) status code communicated back in the HTTP response.
The servlet class generated is loaded using application’s class loader.
An instance of the servlet class is created.
For every servlet mapping declaration of the JSP in the web.xml (similar to servlets), a new instance in addition to the standard JSP file instance is created. If I have a jsp page in the context root, and I have also registered the same JSP page in web.xml, I will have two instances of that JSP created.
You can override this method.
When requests are made, the container calls the generated servlet’s service(request, response) method, which should call the method _jspService(), passing on the request and response parameters.
We should not override _jspService() from our JSP page. This method represents your page source in Java code form—it’s up to the container’s page generators to implementation this method for each individual JSP.
However the JSP spec is flexible enough to accommodate any request /response protocol you wish to implement by overriding this method; and for that only you need to override _jspService method.
Called before the instance of the JSP servlet is nullified and garbage collected
We cannot override servlet lifecycle methods from the JSP code.
The servlet class corresponding to the JSP page is created by the container and hence we cannot create a constructor for the JSP page.