Java Doc for ContextClassLoaderLocal.java in  » Library » Apache-commons-beanutils-1.8.0-BETA-src » org » apache » commons » beanutils » Java Source Code / Java DocumentationJava Source Code and Java Documentation

Occasionally it is necessary to store data in "global" variables (including uses of the Singleton pattern). In applications which have only a single classloader such data can simply be stored as "static" members on some class. When multiple classloaders are involved, however, this approach can fail; in particular, this doesn't work when the code may be run within a servlet container or a j2ee container, and the class on which the static member is defined is loaded via a "shared" classloader that is visible to all components running within the container. This class provides a mechanism for associating data with a ClassLoader instance, which ensures that when the code runs in such a container each component gets its own copy of the "global" variable rather than unexpectedly sharing a single copy of the variable with other components that happen to be running in the same container at the same time (eg servlets or EJBs.)

This class is strongly patterned after the java.lang.ThreadLocal class, which performs a similar task in allowing data to be associated with a particular thread.

When code that uses this class is run as a "normal" application, ie not within a container, the effect is identical to just using a static member variable to store the data, because Thread.getContextClassLoader always returns the same classloader (the system classloader).

Expected usage is as follows:

 public class SomeClass {
 private static final ContextClassLoaderLocal global 
 = new ContextClassLoaderLocal() {
 protected Object initialValue() {
 return new String("Initial value");
 };
 public void testGlobal() {
 String s = (String) global.get();
 System.out.println("global value:" + s);
 buf.set("New Value");
 }
 

Note: This class takes some care to ensure that when a component which uses this class is "undeployed" by a container the component-specific classloader and all its associated classes (and their static variables) are garbage-collected. Unfortunately there is one scenario in which this does not work correctly and there is unfortunately no known workaround other than ensuring that the component (or its container) calls the "unset" method on this class for each instance of this class when the component is undeployed. The problem occurs if:

• the class containing a static instance of this class was loaded via a shared classloader, and
• the value stored in the instance is an object whose class was loaded via the component-specific classloader (or any of the objects it refers to were loaded via that classloader).

Note: A WeakHashMap bug in several 1.3 JVMs results in a memory leak for those JVMs.

Note: Of course all of this would be unnecessary if containers required each component to load the full set of classes it needs, ie avoided providing classes loaded via a "shared" classloader.