When the classloader reports its creator that one of the classes it has loaded has changed on disk, it should discard the classloader and create a new instance using reinstantiate. The classes are then reloaded into the new classloader as required.
The classloader can also load resources, which are a means for packaging application data such as images within a jar file or directory.
The classloader always first tries to load classes and resources from the system, and uses it's own path if that fails. This is also done if an empty repository is passed at construction.
How autoreload works:
The Java VM considers two classes the same if they have the same fully-qualified name and if they were loaded from the same ClassLoader.
There is no way for a classloader to 'undefine' a class once it has been loaded. However, the servlet engine can discard a classloader and the classes it contains, causing the
The JServServletManager creates a new instance of the classloader each time it detects that any of the loaded classes have changed.
Before terminating, all servlets are destroyed.
According to the Java Language Specification (JLS), classes may be garbage-collected when there are no longer any instances of that class and the java.lang.Class object is finalizable. It is intended that this be the case when a JServClassLoader is discarded.
Many VM releases did not implement class garbage collection properly. In such a VM, the memory usage will continue to grow if autoreloading is enable. Running the VM with -verbosegc (or the corresponding option for non-Javasoft VMs) may give some debugging information.
It is important that the destroy method be implemented properly, as servlets may be destroyed and reinitialized several times in the life of a VM.
@author Francis J. Lacoste
@author Martin Pool
@author Jim Heintz
@author Stefano Mazzocchi
@version $Revision: 1.9.2.3 $ $Date: 2001/03/04 03:47:58 $
@see java.lang.ClassLoader
| |