ppkarwasz opened a new issue, #2850: URL: https://github.com/apache/logging-log4j2/issues/2850
As a complement to #1977, we should probably remove the usage of the thread context classloader from `Loader` and `LoaderUtil` in `2.x` The usage of [`Loader.loadClass(String)`](https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/util/Loader.html#loadClass(java.lang.String)) and [`LoaderUtil.loadClass(String)`](https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/util/LoaderUtil.html#loadClass(java.lang.String)) and similar methods is extremely prone to memory leaks, since the result of such a call is often assigned to a static field. The thread context classloader is often the classloader of a web application that can be stopped and restarted at will. Any object that we obtain from it must be kept in a weak reference. IMHO, we should always provide an explicit classloader to load a class by name and we can only choose between: - the classloader that loaded `log4j-core` or `log4j-api`, - the classloader associated with the current `LoggerContext`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
