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) and LoaderUtil.loadClass(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.
As a complement to #1977, we should probably remove the usage of the thread context classloader from
LoaderandLoaderUtilin2.xThe usage of
Loader.loadClass(String)andLoaderUtil.loadClass(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:
log4j-coreorlog4j-api,LoggerContext.