The logging backends supported by the default `LogFactoryImpl` have all
reached their end-of-life (except JUL and `SimpleLog`). Third-generation
logging backends, such as Log4j Core, support multiple logger contexts
per application and therefore can not be handled by the simplified
caching mechanism in `LogFactoryImpl`.
This PR introduces two new `LogFactory` implementations,
`Log4j2LogFactory` and `Slf4jLogFactory`, that forward messages to the
Log4j API and SLF4J.
During initialization the three existing factories are checked in the
following order:
1. the `Log4j2LogFactory` has highest priority, since the Log4j API can
faithfully transmit messages of type `Object`,
2. the `Slf4jLogFactory` is the next choice. However, if the
Log4j-to-SLF4J bridge is present we log directly through SLF4J
instead of the Log4j API.
3. the legacy `LogFactoryImpl` has lowest priority.
[ERROR] C:\Users\ggregory\git\a\commons-logging\src\main\java\org\apache\commons\logging\LogFactory.java:892:
error: header used out of sequence: <H4>
[ERROR] * <h4>ClassLoader conflicts</h4>
[ERROR] ^
* Replace custom code with `ServiceLoader` call
* Files should end with an empty line
* Files should end with an empty line
* Comment empty block
* Comment empty block
---------
Co-authored-by: Gary Gregory <garydgregory@users.noreply.github.com>
This replaces the strong reference to the class loader, `thisClassLoader`,
with a weak one.
The strong ref shows up as causing a GC root after unloading a web app in Tomcat that uses this library.
With these modifications, the GC root is gone...
