Hello I have a query regarding the JSP life cycle.
I want to know what happens when a request for a JSP, say HelloWorld.jsp, is submitted to the server. Does the server look for the HelloWorld.jsp file first to see whether it is actually present ?
Or does it look for the HelloWorld_jsp.class file first and then check whether a newer version of the HelloWorld.jsp exists?
Book by Mike McGrath (JSP in Easy Steps) says that it first looks for the JSP source file i.e. HelloWorld.jsp. If it is not found it will return an error response saying that the requested resource is not found.
But book by Phil Hanna (JSP Complete Reference) does not say anything about looking for the source file first. It merely says that the server looks for the
class file (i.e. servlet with the name HelloWorld_jsp.class). If it is not found, iIt will translate the JSP into servlet, compile the servlet and so on.
I require the answer for an academic reason. Thanks in advance.
After a cursory search, the Servlet/JSP Specifications don't seem to have anything to say on the matter.
I don't think there is any one answer to this question: it is an implementation detail on the server.
Some servers might implement these checks, others might not.
Tomcats implementation is to map all *.jsp requests to a JSP servlet. That servlet would have the logic about checking whether a JSP exists or not.
If you pre-compile your JSPs, and add entries to the web.xml file as a result, then it just goes directly to the compiled servlet from the JSP, and doesn't even touch the JSP Servlet.
So in the case of pre-compiled JSPs you can get a response back even if the JSP file no longer exists.
For any more details I think you would have to dive into the source code.
Joined: May 02, 2012
Thank You Mr. Evans.
I too had gone through the JSP/Servlet specifications as well as Apache documentation and did not manage to find anything there.
Yes. I will have to go though the source code of Tomcat.
Take this as a general guideline. As Bear said, the Tomcat code itself is the final authority, although reading the manual doesn't hurt.
For performance reasons, Tomcat is going to attempt to locate the corresponding class for a JSP and execute it. That saves the overhead of compiling and conforms to the general idea of caching JSP code. If the class file isn't in the cache, then Tomcat will invoke the JSP compiler to digest the JSP into java code (as a servlet), compile that code into a class, which is then placed into the JSP class cache.
If you change the JSP source, Tomcat will detect the change and invalidate (delete) the class file. To the best of my knowledge, the JSP recompilation doesn't occur until the next time the JSP is actually requested (using the caching scheme mentioned above), but the difference between immediate recompilation is in transitory performance, not functionality, so only worry about it if you absolutely must. There may be a Tomcat configuration option to control this.
Changing the Java file that's generated from the JSP source and then compiled to produce the JSP class voids the warranty. Don't even think about it. Always make your changes to the JSP source, never to the generated Java or class files.
Note that JSP source updates will only be detected and applied if the webapp has Tomcat's WAR change scanner switched on. It's switched on by default, but if someone switches it off, changes will not be automatically detected.
In current releases of Tomcat, the JSP class cache is a subtree in the TOMCAT work directory, but of course this is just an implementation detail and therefore subject to change. For best results, however, you should delete this subtree when you deploy a new copy of the WAR just to make sure that no out-of-date JSP classfiles remain.
Customer surveys are for companies who didn't pay proper attention to begin with.