[
https://issues.apache.org/jira/browse/LOG4J2-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187371#comment-15187371
]
Matt Sicker commented on LOG4J2-1312:
-------------------------------------
Also, the web context placeholder only works in synchronous environments as far
as I can tell since it relies on the ThreadLocal.
> 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]
