T
- the type of data stored in an instancepublic class ContextClassLoaderLocal<T> extends Object
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<String> global = new ContextClassLoaderLocal<String>() { protected String initialValue() { return new String("Initial value"); }; public void testGlobal() { String s = 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:
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.
Thread.getContextClassLoader()
Constructor and Description |
---|
ContextClassLoaderLocal()
Construct a context classloader instance
|
Modifier and Type | Method and Description |
---|---|
T |
get()
Gets the instance which provides the functionality for
BeanUtils . |
protected T |
initialValue()
Returns the initial value for this ContextClassLoaderLocal
variable.
|
void |
set(T value)
Sets the value - a value is provided per (thread) context classloader.
|
void |
unset()
Unsets the value associated with the current thread's context classloader
|
void |
unset(ClassLoader classLoader)
Unsets the value associated with the given classloader
|
public ContextClassLoaderLocal()
protected T initialValue()
public T get()
BeanUtils
.
This is a pseudo-singleton - an single instance is provided per (thread) context classloader.
This mechanism provides isolation for web apps deployed in the same container.public void set(T value)
value
- the object to be associated with the entrant thread's context classloaderpublic void unset()
public void unset(ClassLoader classLoader)
classLoader
- The classloader to unset forCopyright © 2000–2019 The Apache Software Foundation. All rights reserved.