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

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

    [ https://issues.apache.org/jira/browse/LOG4J2-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294696#comment-17294696 ] 

Romain Manni-Bucau edited comment on LOG4J2-1312 at 3/3/21, 5:47 PM:
---------------------------------------------------------------------

Not handy but should be reproducable deploying a war which fail in a listener after log4j one, the thread local will never be cleaned. If log4j is in tomcat/lib another webapp can inherit form it (and use it) whereas in other cases it will just leak mem.


was (Author: romain.manni-bucau):
Not handy should be reproducable deploying a war which fail in a listener after log4j one, the thread local will never be cleaned. If log4j is in tomcat/lib another webapp can inherit form it (and use it) whereas in other cases it will just leak mem.

> 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)