[
https://issues.apache.org/jira/browse/LOG4J2-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187411#comment-15187411
]
Romain Manni-Bucau commented on LOG4J2-1312:
--------------------------------------------
The context listener init assume the filter will clean it
https://github.com/apache/logging-log4j2/blob/master/log4j-web/src/main/java/org/apache/logging/log4j/web/Log4jServletFilter.java#L57
(and the opposite for destruction) but this is pretty nasty and not sure it
can be that reliable.
https://github.com/apache/logging-log4j2/blob/master/log4j-web/src/main/java/org/apache/logging/log4j/web/Log4jServletContainerInitializer.java#L62
states the async is not a goal from my understanding which is confirmed by
https://github.com/apache/logging-log4j2/blob/231241c3fdf1119d8b3fcc419b9191ffc9f0eb3e/log4j-web/src/test/java/org/apache/logging/log4j/web/TestAsyncServlet.java
(side note: wrapping the request would be it potentially transparent is async
context is correctly wrapped).
In any case I think the web module should get some love or get exlpicitely not
recommanded cause we regularly get complains about this part and it is sad
cause other parts of log4j are great.
> 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]
