3.2 Servlet Reloading

Java Servlet Programming, 2nd Edition > 3. The Servlet Lifecycle > 3.2 Servlet Reloading

< BACK

CONTINUE >

If you tried using these counters for yourself, you may have noticed that any time you recompiled one, its count automatically began again at 1. Trust us it's not a bug, it's a feature. Most servers automatically reload a servlet after its class file (under the default servlet directory, such as WEB-INF/classes) changes. It's an on-the-fly upgrade procedure that greatly speeds up the development-test cycle and allows for long server uptimes.

Servlet reloading may appear to be a simple feature, but it's quite a trick and requires quite a hack. ClassLoader objects are designed to load a class just once. To get around this limitation and load servlets again and again, servers use custom class loaders that load servlets from special directories such as WEB-INF/classes.

When a server dispatches a request to a servlet, it first checks whether the servlet's class file has changed on disk. If it has changed, the server abandons the class loader used to load the old version and creates a new instance of the custom class loader to load the new version. Some servers improve performance by checking modification timestamps only after some timeout since the previous check or upon explicit administrator request.

In Servlet API versions before 2.2, this class loader trick resulted in different servlets being loaded by different class loaders, a situation that would sometimes cause a ClassCastException to be thrown when the servlets shared information (because a class loaded by one class loader is not the same as the class loaded by a second class loader, even if the underlying class data is identical). Beginning in Servlet API 2.2, it's mandated that these ClassCastException problems must not occur for servlets inside the same context. So most server implementations now load each web application context within a single class loader and use a new class loader to reload the entire context when any servlet in the context changes. Since all servlets and support classes in the context always have the same class loader, there will be no unexpected ClassCastException during execution. Reloading the entire context causes a slight performance penalty, but one that occurs only during development.

Class reloading is not performed when only a support class changes. For efficiency, servers check only the servlet class timestamp to determine whether to reload a context. Support classes in WEB-INF/classes may be reloaded when a context is reloaded, but if the support class is the only class to change, the server most likely won't notice.

Servlet reloading also is not performed for any classes (servlet or otherwise) that are found in the server's classpath. These classes are loaded by the core, primordial class loader, not the custom class loader necessary to do the reloading. Such classes are loaded once and retained in memory even when their class files change.

It's generally best to put global support classes (such as the utility classes in com.oreilly.servlet) somewhere in the server's classpath where they don't get reloaded. This speeds the reload process and allows servlets in different contexts to share instances of these objects without hitting a ClassCastException.

< BACK

CONTINUE >