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

Romain Manni-Bucau commented on LOG4J2-1312:
--------------------------------------------

Not using web module solves it but you loose the web feature and one of the 
most asked if the webcontext placeholding. That said the plain naked tomcat 
case still leaks the config and one webapp can use the config of another one.

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

Reply via email to