Hello. Le ven. 19 déc. 2025 à 12:55, Piotr P. Karwasz <[email protected]> a écrit : >> [...] > [...] > > First, Commons Logging is generally sufficient for Commons libraries. > Commons projects are foundational libraries; they tend to log sparingly > because meaningful diagnostic context usually exists at higher layers of > an application. In practice, errors and failures are communicated via > exceptions rather than logging.
This is not universally true; IOW even if logging needs to be turned off most of time in low-level layers of an application (also because of the lack of sufficient context as you say), there have been times where logging can be quite useful, and it was a liability that some components did not have them. [At the time, the argument (for not introducing logging) was that it would hinder performance, even if at the end the log message would not be output by the underlying framework.] > Second, there is a significant overlap between the Commons PMC and the > Apache Logging Services PMC. If Commons projects were to reconsider > their logging API at some point, the more natural direction would be > toward the Log4j API [1], not SLF4J. The Log4j API is newer (initially > released in 2014 rather than 2004), actively evolved, and includes > capabilities such as structured logging that SLF4J has only added quite > recently. I imagine that "slf4j" became quite popular because it was the first to introduce the decoupling between API and implementation. And also it provided a solution to the performance problem via the "no-op" implementation. Many years passed before "Log4J" had the same. [And it was deemed "too heavy" a dependency for "light-weight" and low-level "Commons" components.] > Third, on a more personal note, I have some concerns regarding the > long-term sustainability and governance of SLF4J. It remains a > single-maintainer project, with no publicly documented succession plan. > This point is also highlighted in the recent Logback security audit [2]: > > “Currently, the main owner of the project holds all access rights” > > “Open-source organizations are advised to back up the sole developer > of critical components, by increasing the number of trusted > individuals responsible for reviewing code modifications.” > > Together with Christian and Volkan, we previously attempted to address > this situation by proposing a community-governed logging facade based on > SLF4J (Jakarta Logging [3]). The broader ecosystem, however, preferred > to maintain the status quo. That's a pity. Now that "Log4J" (and maybe others) followed in the footsteps of "slf4j", so that everyone seems to agree (?) how a logging framework should be designed, it would be nice to have a unique API. > If there is ever a change in this area, it would more likely happen as > part of a hypothetical Commons Logging 2.0, allowing us to selectively > adopt the best features of existing logging APIs rather than switching > wholesale to another facade. There has never been any proposal to move "log4j-api" to Commons. Although that would make perfect sense (if "Commons" means what it means). Instead I seem to recall discussions many years ago about issues with Commons Logging, e.g. how inefficient it could be to route message through it. This was when "slf4j" was gaining wide acceptance; so that by the time the issues with Commons Logging were solved (?), new projects weren't unlikely to adopt it anymore. Regards, Gilles > [...] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
