The Effect of Class Loading on Application Logic | Professional Java Servlets 2.3

< Free Open Study >

Our choice of where to deploy classes can have a subtle but often significant effect on the logic of an application. If we deploy classes in the wrong place, or if we fail to understand the class loading precedence, our application may not behave in the way that we expect. Let's look at an example.

A User Tracking Application

Consider the following simple class, which can be used to track the users that are logged in to the system. Each time the user logs in we'll use the static login() method as a factory method to instantiate and return a new User instance. As each instance is created the constructor increments the static users variable to keep count of the total number of users that have logged in:

     package classloading;     public class User {       public static int users = 0;       public static User login() {         return new User();       }       public User() {         users++;       }       public static int getUsers() {         return users;       }     }

Users will log in by invoking LoginServlet:

     package classloading;     import java.io.*;     import javax.servlet.*;     import javax.servlet.http.*;     public class LoginServlet extends HttpServlet {       public void doGet (HttpServletRequest req, HttpServletResponse res)           throws ServletException, IOException {         User thisUser=new User();         PrintWriter writer = res.getWriter();         writer.println("<html><head></head>");         writer.println("<body style=\"font-family:verdana;font-size:8pt\">");         writer.println("<b>"+ User.getUsers() + "</b> users now logged in.");         writer.println("</body></html>");         writer.close();       }     }

We're not worried about security in this example, so no user name and password is requested. The servlet reports back the total number of users on the system by calling the static method getUsers() of User.

Deploying the Application

We'll deploy this application in two separate contexts, TestContext1 and TestContext2:

     %CATALINA_HOME%/webapps/TestContext1/WEB-INF/classes/User.class     %CATALINA_HOME%/webapps/TestContext1/WEB-INF/classes/LoginServlet.class     %CATALINA_HOME%/webapps/TestContext2/WEB-INF/classes/User.class     %CATALINA_HOME%/webapps/TestContext2/WEB-INF/classes/LoginServlet.class

After running LoginServlet from both contexts in that configuration we'll remove the User class from those deployed locations and put it instead into Tomcat's lib directory, in its own JAR. The second configuration will look like this:

     %CATALINA_HOME%/webapps/TestContext1/WEB-INF/classes/LoginServlet.class     %CATALINA_HOME%/webapps/TestContext2/WEB-INF/classes/LoginServlet.class     %CATALINA_HOME%/lib/user.jar

Testing the User Tracking Application

In the first configuration we invoke LoginServlet from the first context until we have logged in five users:

click to expand

Then we invoke LoginServlet in the second context just once, so that there is a single user logged in:

click to expand

In this configuration each application is maintaining its own count of users, because in each case the User class has been loaded from the web context of the application. Two contexts means two separate occurrences of the User class, and two separate occurrences of the static users variable.

Static variables of a class deployed in the WEB-INF/classes or WEB-INF/lib directories will be consistent within the application context.

In the second configuration we see quite different behavior. Again we run up five users in the first context, but then our first attempt in the second context yields this result:

click to expand

In this configuration a single count of users is maintained across all application contexts, because in each case the User class has been loaded from the same location.

Static variables of a class deployed outside of the WEB-INF/classes or WEB-INF/lib directories may be shared across application contexts.

The implication is clear. What the programmer intends at development time can be affected by the decisions made at deployment time, so take care when deciding where classes should be deployed. Do we want the class, and the values it holds, to be loaded from a common location and shared between applications? Or do we want each application to load its own private version of the class, that is not visible to other applications?

< Free Open Study >