[
https://issues.apache.org/jira/browse/LOG4J2-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294340#comment-17294340
]
Romain Manni-Bucau commented on LOG4J2-1312:
--------------------------------------------
[~rgoers] don't think it got solved so still an issue with webapp "runtime"
deployments.
> 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
> Priority: Major
>
> 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
(v8.3.4#803005)
