Note that in Java the identity of a class is not only defined by the class name but also by the ClassLoader by which it was loaded. Web servers usually load each Servlet with a different class loader. This is necessary to reload Servlets on the fly because single classes cannot be replaced in the running JVM. Only a ClassLoader object with all loaded classes can be replaced.
doubt 1 Web servers load each servlet with a different class loader? why is that...we will have many servlets,so does that mean we will have that many class loaders?I always thought we had only one class loader and it will help us load the classes
doubt 2This is necessary to reload Servlets on the fly because single classes cannot be replaced in the running JVM. Only a ClassLoader object with all loaded classes can be replaced.
Above "doubt2" is not clear at all.
This means that classes which are loaded by a Servlet class loader cannot be used for inter-Servlet communication. A class literal FooServlet (as used in a type cast like "FooServlet foo = (FooServlet)context.getServlet("FooServlet")") which is used in class BarServlet is different from the class literal FooServlet as used in FooServlet itself.
doubt 1A class literal FooServlet (as used in a type cast like "FooServlet foo = (FooServlet)context.getServlet("FooServlet")") which is used in class BarServlet is different from the class literal FooServlet as used in FooServlet itself.
I always thought class literal means or say formed by taking a type name and appending ".class"; for example, String.class
So why are two class literals different??
Thanks in advance....
Someone says "Impossible is nothing". The man next him says "Let me see you licking your elbow tip!"
Web Container creates single instance of each servlet. Call init on it and then call service on that same instance for each of the subsequent request.
Container tend to load each servlet with different class loader to make sure the hot deployment. Hot deployment is enabled in most of the servers which means whenver there is change in one class/servlet container automatically reload that class again. So if you need to load a separate set of classes including the new servlet and other dependent classes you need to load it while not disturbing other classes.
Single classes can not be reloaded on the fly because there is always a hierarchy of class loaders in JVM and if some class loaded in parent class loader changes , it can break other dependencies.
In it, you'll see that there is a separate link for each application within the server but nothing is mentioned about having a separate loader for each servlet.
A more fun way to learn about class class loaders is to put some print statements into a web app and start hitting it.
The following line will print the classloader information for the current class to the logs (or console depending on how your container is configured)
I just did this in a small test app. I put the statement in two servlets and then ran them.
From the output, you can see that both servlets are using the same classloader.
This makes sense because, in Tomcat, you can not reload a single servlet. You have to reload the entire app if you change a servlet.
With modern JEE programming, you probably wouldn't want a container to reload a single servlet as many apps these days are built with frameworks that only have one servlet that acts as a controller. Often this controller holds references to other Java objects within the app. Reloading just the controller without the rest of the app could cause very hard to trace bugs.
An interesting note:
The Jasper JSP engine used by Tomcat does create separate classloaders for each JSP.
This makes sense because JSPs need to be able to be reloaded whenever a change is made to them.
To print the classloader information in a JSP
The results after pasting that line into two different JSPs and hitting them:
Also, if you hit a JSP, and then update the code in it and hit it again, you'll see that a new class loader gets created: