You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Mauro Molinari (JIRA)" <ji...@apache.org> on 2014/11/19 16:44:33 UTC

[jira] [Created] (LOG4J2-903) ClassLoaderContextSelector uses ClassLoader.toString() as a key

Mauro Molinari created LOG4J2-903:
-------------------------------------

             Summary: ClassLoaderContextSelector uses ClassLoader.toString() as a key
                 Key: LOG4J2-903
                 URL: https://issues.apache.org/jira/browse/LOG4J2-903
             Project: Log4j 2
          Issue Type: Bug
          Components: Core
    Affects Versions: 2.1
            Reporter: Mauro Molinari


{{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...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org