ppkarwasz commented on PR #3372: URL: https://github.com/apache/logging-log4j2/pull/3372#issuecomment-2979985822
Hi @norrisjeremy, Thanks for your thoughtful and detailed questions—these are all excellent points, and I really appreciate you taking the time to raise them. > 1. So why weren't all the other wither methods replaced with setters and marked as deprecated too? You're absolutely right to highlight the inconsistency. The focus of the PR was to correct a specific issue with `withtFilter` (with an additional `t`), and the introduction of `setFilter` was a side-effect driven by the fact that `withFilter` is already deprecated in `3.x`. So it made sense to align it preemptively here. Replacing all wither methods in the same Log4j Core plugin—or across all plugins—would indeed be more consistent. But that would have significantly expanded the scope of this PR. Since there are around 300 plugins, we felt it was better to handle that broader change separately. To address this, I’ve opened issue #3750 to track the work of adding setters and deprecating all remaining withers. If you're interested, contributions are always welcome! > 2. And why wasn't [issue #1206](https://github.com/apache/logging-log4j2/issues/1206) referenced in the PR?** It was actually mentioned in a resolved conversation here: https://github.com/apache/logging-log4j2/pull/3372#discussion_r1957283823 > 3. Why wasn’t this change documented in the `Deprecated` section of the Release Notes? That’s a fair point. When preparing release notes, we tend to prioritize high-impact changes for the majority of users, most of whom use Log4j via configuration files. The Log4j Core internal API is mostly used by Log4j Plugin developers and integrators. As a result, API-level changes like this one can get less visibility, especially if they're part of a narrowly scoped fix. That said, you're absolutely right: this deprecation should have been classified as `deprecated`, not just `changed`. Feel free to submit a PR correcting that in the release notes—those are always welcome, even after the release, and can help future users. > From a user's perspective, this change seems poorly implemented and documented, which is extremely frustrating. I hear you, and I’m sorry the process came across that way. We always aim to provide a stable and predictable experience, and clearly we can improve how we communicate these kinds of changes. Out of curiosity—what kind of impact did this deprecation have on your application? Was it mainly the compiler warnings, or something else? Understanding that might help us improve how we handle and communicate such changes going forward. Thanks again for your feedback—it’s valuable and helps us improve the project for everyone. -- 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: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
