[
https://issues.apache.org/jira/browse/LOG4J2-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14226043#comment-14226043
]
Mauro Molinari commented on LOG4J2-903:
---------------------------------------
Hi Ralph,
thanks for your feedback. Do you think a fix for the {{LoggerContext}} lookup
could be provided soon? Because currently Log4j 2 can't be used reliably in
Tomcat whenever load time weaving is used.
> 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: [email protected]
For additional commands, e-mail: [email protected]
