You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I support this idea; to be more precise: to replace TCCL-as-a-fallback usages with CLs of log4j-core, log4j-api, or LC.
By default TCCL is not a fallback, it is the first one used. That is what makes it so dangerous. The ClassLoader of the LC should be its replacement, which should solve one of the problems we have in a Jakarta environment: if Log4j Core is in the system classloader, you can not use the Web Lookup in a web application classloader.
As a complement to #1977, we should probably remove the usage of the thread context classloader from
Loader
andLoaderUtil
in2.x
The 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-core
orlog4j-api
,LoggerContext
.The text was updated successfully, but these errors were encountered: