Hi All, Thanks for your great feedback. Before discussing this issue further, here are some context.
As you already know, the log4j vulnerability crisis was a significant issue recently. Of course, using slf4j as a facade and making log implementation pluggable is THE SOLUTION but, it has one limitation: as Gülcü already stated, slf4j does not support dynamic log level change feature, which is such a desirable feature for maintenance. Because of that, many projects can't use slf4j. For example, Apache Kafka calls log4j API directly, and Spring boot uses logback, without the slf4j facade. (related discussion: https://lists.apache.org/thread/4gyyjmfp92xvl1661qdgpx70l0gg04yd disclaimer: I am working on Apache Kafka's log4j 2.x upgrading issue.) Upon the context above, I hope to propose the following features to slf4j-api: 1. Add OFF level, which enables dynamic turning on/off the logger. 2. Upon 1 and SLF4J-124, add Logger#setLevel(Level) method. With this feature, for example, `slf4j-simple` can dynamically adjust its logger level (`SimpleLogger#currentLogLevel`): https://github.com/qos-ch/slf4j/blob/master/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java How do you think? Best, Dongjin On Fri, Jan 28, 2022 at 4:40 AM Matt Sicker <boa...@gmail.com> wrote: > It might be beneficial to support the equivalent of levels by > interpreting them as integral values. log4j-api supports custom log > levels, and those all work due to levels having an integral value to > compare them against each other. From a Logger API perspective, it > doesn't really make sense to log messages at OFF or ALL, especially as > they tend to do the opposite of their name (e.g., logging at the OFF > level means "always log" as OFF is a higher level than FATAL, while > logging at the ALL level means it never gets logged as ALL is lower > than TRACE). > > On Thu, Jan 27, 2022 at 9:57 AM Joakim Erdfelt <joakim.erdf...@gmail.com> > wrote: > > > > While slf4j is just a facade, there's a growing group of features in > various projects that put configuration at the slf4j api level (both at > startup and runtime), not at the slf4j implementation level. > > > > Am I wrong in assuming that the stated scope of this was for this > proposal to have slf4j api level ability? > > > > - Joakim > > > > On Thu, Jan 27, 2022 at 8:42 AM Ceki Gülcü <c...@qos.ch> wrote: > >> > >> > >> > >> On 1/27/2022 2:55 PM, Joakim Erdfelt wrote: > >> > I like it. > >> > > >> > OFF is definitely useful, and should be there. > >> > > >> > ALL on the other hand seems redundant. > >> > Just setting the most noisy level (TRACE in slf4j terms) would be the > >> > equivalent end result. > >> > >> Unless I am forgetting something or getting forgetful, SLF4J does not > >> allow users to set levels. > >> > >> > - Joakim > >> > >> -- > >> Ceki Gülcü > >> > >> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch > >> _______________________________________________ > >> slf4j-user mailing list > >> slf4j-user@qos.ch > >> http://mailman.qos.ch/mailman/listinfo/slf4j-user > > > > _______________________________________________ > > slf4j-user mailing list > > slf4j-user@qos.ch > > http://mailman.qos.ch/mailman/listinfo/slf4j-user > _______________________________________________ > slf4j-user mailing list > slf4j-user@qos.ch > http://mailman.qos.ch/mailman/listinfo/slf4j-user -- Dongjin Lee A hitchhiker in the mathematical world. github: github.com/dongjinleekr keybase: https://keybase.io/dongjinleekr linkedin: kr.linkedin.com/in/dongjinleekr speakerdeck: speakerdeck.com/dongjin
_______________________________________________ slf4j-user mailing list slf4j-user@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-user
