5. Define the binary compatibility requirements. Gary
On Tue, May 3, 2022, 09:38 Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi everyone, > > This topic has been discussed several times, but the list of features that > need to be in version 3.0 is still fuzzy to me. From what I gathered > version 3.0 requires: > > 1. JPMS support with non-automatic modules. This seems to be done for > `log4j-api`, `log4j-plugins` and partially for `log4j-core`. The remaining > modules need to be converted and I think there are still some classes if > `log4j-api`, `log4j-plugins` and `log4j-core` that we can move to private > packages. For example all the implementations of `PropertySource` in > `log4j-api` do not need to be exported. > > 2. A DI system, which is certainly ready. However there are still places in > the code where it is not used. For example the managers are still directly > instantiated by the appenders, as well as some `log4j-1.2-api` builders > that require constructor parameters. > > 3. The properties enhancement ( > https://cwiki.apache.org/confluence/display/LOGGING/Properties+Enhancement > ) > proposed by Ralph. Personally I would like a `log4j-api` jar common to > multiple web applications to be able to correctly detect a per-webapp > `log4j2.configurationFile` property. > > 4. We could profit from the major version change to move some things > around: for example do we really need three different file appenders? I > think that from a use perspective a single `FileAppender` with three > different file managers would be more intuitive. > > Piotr >
