search

apache / logging-log4j2

Apache Log4j 2 is a versatile, feature-rich, efficient logging API and backend for Java.
https://logging.apache.org/log4j/2.x/
Apache License 2.0
3.4k stars 1.62k forks source link

Deprecate usage of TCCL in `Loader/LoaderUtil` #2850

Open ppkarwasz opened 2 months ago

ppkarwasz commented 2 months ago

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:

vy commented 2 months ago

I support this idea; to be more precise: to replace TCCL-as-a-fallback usages with CLs of log4j-core, log4j-api, or LC.

ppkarwasz commented 2 months ago

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.