This PR removes Lumberjack and Log4j 1.x for the automatic logging
backend discovery procedure.
The updated procedure is documented in the guide.
This closes LOGGING-173 and LOGGING-188.
* Fix names of deployed artifacts
We remove the obsolete `finalName` property and fix the Maven Failsafe
executions.
* Fix failing tests
* Reenable integration tests
* Disable SecurityManager tests on Java 21
* Simplify build workflow
* Set `fail-fast` to false
* Fix NPEs caused by `String.trim()`
* Span a different JVM per test case
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.
* 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...
