ppkarwasz commented on PR #2175: URL: https://github.com/apache/logging-log4j2/pull/2175#issuecomment-1884811407
Yes, I am sure. This was discussed in at least two meetings. I don't know if you were present, but @rgoers and @garydgregory can probably confirm. We need to categorize the breaking changes into at least 3 categories: 1. those that break most users code/binaries and we MUST NOT introduce them, 2. those that break some users code/binaries and we SHALL NOT introduce them, 3. those that only break the code of Log4j component providers and we MAY introduce them. The `Supplier` class is referenced in the signature of `Logger` methods and is used by early adopters that didn't want to wait ~8 years for SLF4J to offer the same functionality. Your proposed change is source compatible, but it is not binary compatible, I could honestly not accept it. I would categorize the changes in #2171 as category 2: I strongly believe that not many users reference `ParameterizedMessageFactory` in their code (even if `MessageFactory` is in signatures of `LogManager` methods). Same goes for `Logger#entry` and `Logger#exit`. Regarding `log4j2-logstash-layout`, you used a class that was in a private package (`o.a.l.l.util`), so you were aware of the consequences. ;-) **Remark**: Of course I know that `Supplier` is also in `o.a.l.l.util`. When you look closely at the way packages interact, you understand that the subdivision into packages is chaotic and every breaking change in `log4j-api` requires an exhausting analysis. Since SLF4J also has these API leakage properties (e.g. [`Logger`](https://www.slf4j.org/api/org/slf4j/Logger.html) references [`LoggingEventBuilder`](https://www.slf4j.org/api/org/slf4j/spi/LoggingEventBuilder.html) that is not in the API, but in the SPI package), can we move this PR to 4.x, when we'll have all the time to discuss every API break? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
