On the compatibility front, it would be useful to figure out which parts of 
core are expected to remain compatible. Different plugin types will likely have 
different expectations of compatibility.
—
Matt Sicker

> On May 3, 2022, at 10:11, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> 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
>> 

Reply via email to