Deprecate usage of TCCL in `Loader/LoaderUtil`

[ppkarwasz]

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.

[vy]

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]

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.