[jira] [Created] (LOG4J2-1312) org.apache.logging.log4j.web.Log4jServletContextListener leaking

["Romain Manni-Bucau (JIRA)" <ji...@apache.org>]

Romain Manni-Bucau created LOG4J2-1312:
------------------------------------------

             Summary: 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
            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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org