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 lim
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
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 lev
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 fo
Hello Dongjin,
Thank you very much for your very well researched message.
While the SLF4J API allows for logging at levels TRACE, DEBUG, INFO,
WARN and ERROR, the API does *not* allow the user to set the level of a
logger.
I would say that given that it makes no sense to log at levels OFF or
ON,
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.
- Joakim
On Thu, Jan 27, 2022 at 7:37 AM Dongjin Lee wrote:
> Hi, slf4j community,
>
> I have a questio
