Commons Logging has a fallback simple logger that is used if the
`java.util.logging` package is not present.
Originally this only could happen with Java 1.3, but sinc Java 9 the
user can disable the `java.logging` JPMS module. Commons Logging will
work anyway.
This PR slightly modifies the inherited Moditect configuration to add a
`static` (i.e. optional) modifier to the `java.logging` module.
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.
Piotr P. Karwasz