Hi all, On 13.09.2026 22:59, Piotr P. Karwasz wrote: > On the alleged contract: `log4j1.compatibility` gates the *programmatic* > use of `DOMConfigurator` and `PropertyConfigurator`. It has never gated > Log4j's support for the Log4j 1.x *configuration file formats*. Pointing > `log4j.configuration` at a Log4j 1.x configuration file enables that > support on its own, by design and for backward compatibility -- Log4j > has auto-detected `log4j.properties` and `log4j.xml` on the class path > since Log4j 1.0. No documented contract is broken.
This could be clearer: - log4j1.compatibility: gates *programmatic* configuration since 2.24.x. - log4j1.compatibility: also gates auto-detection of `log4j.properties` and `log4j.xml` files on the class path. - log4j.configuration is the only configuration property you need to point Log4j Core to a Log4j 1 configuration. BTW: Log4j 1 compatibility should be something from the past right now. You only need it: - If you have a large user base that wrote their own Log4j configuration files. For your own application, converting a log4j.properties file into a log4j2.xml file is a one time task. - If you have custom Log4j 1 components (appenders, layouts). With Log4j Core 2 you probably don't need those, since we have a large ecosystem of plugins. - If you depend on an old library that calls org.apache.log4j.Logger directly. This is highly unlikely, since libraries have started migrating from direct usage for Log4j 1 to facades like Commons Logging, SLF4J or Log4j 2 API since 2004. We have a detailed guide one how you can remove the need for log4j-1.2-api in your application: https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
