JSP and ClassLoader

Explain how class loaders work with JSP, and how is that different than servlets.

Can you have a JSP application that is nearly static, with many thousands of megabytes of JSP pages?

How come it is possible to replace a JSP page with a fresher version, and the servlet behind the JSP page gets reloaded. But it doesn't work the same way with a servlet. In the case of a JSP, only the one JSP page is recompiled, and users do not loose their sessions. In the case of servlets, if it works at all, replacing the servlet will restart the entire web application.
Who is Participating?
This is due to implementation of various application servers.

App Servers will do "page translation".  When a web container recieives a request for JSP for the first time or when restarted (some application servers allow you to precompile JSPs).  Most app servers out there will perform "page translation" every time the JSP is modified.

Some application servers load servlets into memory when they start due to performance reasons.  Some app servers auto-restart when a servlet class file is replaced and others require a manual restart.  You can setup your session appropriately you will not lose sessions btw restarts.

for any replacements of JARs or WARs.  A restart is required.

I am not sure if this specifically answers your questions but hopefully has shed some light on things.

I ran into this info about Tomcat:

"Turn on Servlet Reloading To tell Tomcat to check the modification dates of the class files of requested servlets and reload ones that have changed since they were loaded into the server's memory. This degrades performance in deployment situations, so is turned off by default. However, if you fail to turn it on for your development server, you'll have to restart the server every time you recompile a servlet that has already been loaded into the server's memory. To turn on servlet reloading, edit install_dir/conf/server.xml and add a DefaultContext subelement to the main Service element and supply true for the reloadable attribute. The easiest way to do this is to find the following comment: <!-- Define properties for each web application. This is only needed if you want to set non-default properties, or have web application document roots in places other than the virtual host's appBase directory. --> and insert the following line just below it: <DefaultContext reloadable="true"/> Be sure to make a backup copy of server.xml before making the above change."

This is supposedly true for WARs and JARs too.

Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

mjzalewskiAuthor Commented:
OK let me rephrase the question.

How is it possible to have a large number of JSP pages (hundreds of megabytes) in a web application? Why doesn't the JVM run out of memory, because each JSP page must be compiled into a servlet, and servlets don't normally unload once started.

My second, probably related question is:

When you replace a .jsp file with a newer version, the application server recompiles the .jsp and runs it as a new servlet. You can also replace a servlet .class file, or a .jar file used by the servlet, and the new version of the servlet can be reloaded automatically. But when this happens, *everything* is reloaded, including all actively running web sessions, and all the other servlets in the web application. Why is it different?

Part of the answer to the first question might be because JSP pages compile into servlets that read the static parts from a file. So the servlet .class file is actually much smaller than the original JSP page.

But I am almost certain that is not the whole anser. Something different happens when a JSP page reloads. Each JSP page can be reloaded without affecting the other ones. The same is not true of a servlet. Changing the .class file for a servlet causes the entire web application to reload.

It must be that there is a seperate class loader for JSP than for servlets. Probably a seperate instance of a class loader for each JSP page. That way, the Class object for the JSP servlet can be released from memory when the JSP servlet is no longer in use.

And if this analysis is true, there is no limit on the number of JSP pages you can have in an application. So if this is true, the answer to my question is:

You can have as many JSP pages as you want, because the inactive JSP Class objects will be unloaded. The Application server can unload JSP servlet Class objects because each one is loaded with a seperate instance of a ClassLoader.

And the answer to my second question might be:

JSP pages can be replaced in a running application because each JSP has a different instance of a ClassLoader. When the application server needs to make a new JSP servlet, it makes a new ClassLoader and releases the old one. Servlets are loaded with a single instance of a ClassLoader. So the only way to reload a servlet is to release the ClassLoader, which causes all of the other servlet classes to be reloaded.

Not sure if any of the above is correct, or even if it makes sense.
mjzalewskiAuthor Commented:
The section on USING CLASS LOADERS FOR HOT DEPLOYMENT was approximately what I was looking for. I guess I was looking for a more complete explanation of how JSP pages in particular use class loaders.

But this information allows me to connect the dots. Thanks for the reference!
No worries.
I'd guess the details of how it's handled for jsp may depend on which container you are using.

Brainbench MVP for Java 1
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.