[
https://issues.apache.org/jira/browse/LOG4J2-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187366#comment-15187366
]
Matt Sicker commented on LOG4J2-1312:
-------------------------------------
I honestly don't even know why there's a ThreadLocal being used to cache the
LoggerContext as it is. Clearly that wouldn't work with async servlets anyway,
so the LoggerContext has to be looked up through the ContextSelector anyways
(when obtaining a logger for the first time).
> org.apache.logging.log4j.web.Log4jServletContextListener leaking
> ----------------------------------------------------------------
>
> Key: LOG4J2-1312
> URL: https://issues.apache.org/jira/browse/LOG4J2-1312
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.5
> Reporter: Romain Manni-Bucau
>
> org.apache.logging.log4j.web.Log4jServletContextListener calls
> this.initializer.setLoggerContext(); and
> this.initializer.clearLoggerContext(); in respectively contextInitialized and
> contextDestroyed. By default it sets/resets a thread local. There is no
> guarantee to reuse the same thread for undeployment than for deployment so it
> doesn't really work + it leaks for all deployments in between so it is
> possible a webapp reuse the context of another webapp in between.
> The only way to move one step forward is to be able to lookup the servlet
> context by classloader IMO but this still has the issue a lot of things -
> including logging - can happen before the servlet context is available and
> here the application can't use these features so wonder if it shouldn't be a
> way to configure the servlet context representation log4j uses in log4j2.xxx
> for such cases (ex: tomee starts CDI before servlets to ensure injections can
> be done properly in servlets but then you can't log in CDI lifecycle using
> log4j2).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
