Major Description
org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoader, URI) uses the ClassLoader.toString() as a key to find a context in the CONTEXT_MAP. However, there are cases in which this string may change with time, for the same class loader instance.
The example is the Tomcat class loader, which changes its toString() value whenever a transformer is added (to do load time weaving).
I discovered this when I encountered the problem described at:
http://stackoverflow.com/questions/27016854/tomcatloadtimeweaver-breaks-log4j-2
This phenomenon leads to the webapp completely "lose" the Log4j configuration.
I think the hashCode() or even the System.identityHashCode() should better fit the necessity to reliably retrieve a context associated with a class loader. And what about using the class loader itself as the map key?
By the way, the use of a WeakReference further concerns me about the reliability of the context lookup when the memory pressure is high...