I am onboard with your thoughts Ralph; replacing 2.x JARs with 3.x rather than keeping both, sticking to `log4j2.xml`, keeping API compatible with 2.x, etc. Though I also think 3.x constitutes a good opportunity to lose some extra weight: deprecated or superseded Maven modules. (I know you are addressing Gary's concerns and this was not exactly one of the points he raised. Nevertheless, I wanted to share mine.)
I propose discussing this subject in our next video call on May 1st – I've updated the meeting notes to include this subject. Oh... By the way, thanks so much for taking time to share these comments with us. I really appreciate them; they not only provide new perspectives to consider, but also highlight certain historical accounts. Please keep these emails coming. 💯 On Tue, Apr 19, 2022 at 11:13 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > Gary has suggested that Log4j 3.x should be able to break binary > compatibility since it is a new major version and somehow should be able to > coexist side by side with Log4j 2. I am not really sure where he got that > idea but I am going to try to explain why that is not workable. > > First, to have both Log4j 2.x and 3.x able to coexist they would need to > have separate packages, presumably by appending a “3” all over the place as > Commons has done with its projects. We would then have to change all the > artifact ids to include the “3”. This would be a lot of work. So lets > assume we do that. What next? > > If a user says they have Logback and Log4j both in their project what is > our advice? We tell them to use the SLF4J bridge to route everything to > Log4j and remove the Logback jar. Why do we do this? Because no one wants > to logging configuration files and having multiple logging systems writing > to the same locations is asking for trouble. So to make this work we would > need to create a bridge from Log4j 2.x to Log4j 3.x. This would mean > creating a bridge that is a clone of 2.x but binds with 3.x. Doesn’t that > seem silly when we can just keep the 3.x API compatible with 2.x? > > Next comes the problem of configuration files. Both Log4j 2.x and 3.x use > log4j2.xml. Changing log4j2.xml (or yaml, json, properties) to log4j3.xml > would impact lots of users. But the contents of the file wouldn’t have > changed - we haven’t changed anything that affects the configuration format > in 3.x So this change would only exist so you could tell which > configuration was for Log4j 2.x and which was for 3.x if they are both > present. So lets assume we leave it as log4j2.xml. This means if both are > present that they both will find the same file and try to use it. Now we > are back to the same problem of having two logging systems trying to write > to the same destinations. That is a mess. > > So while repackaging might work for Commons projects it will cause nothing > but problems for Log4j and users would hate us for it. I know I would hate > us for it since I would have to deal with it in my own projects. > > So the bottom line is that we have to maintain compatibility between the > releases. But I am sure that some of the classes we removed will not break > compatibility. We just need to analyze what was removed and add back those > that will affect users. > > Ralph
