Closed meowcat closed 1 year ago
Would it be enough for your case to define a custom log level, or actually override SUCCESS
, see e.g.:
> library(logger)
> SUCCESS <- structure(250L, level = 'SUCCESS', class = c('loglevel', 'integer'))
> log_success <- function(...) log_level(SUCCESS, ...)
>
> log_threshold(WARN)
>
> log_info(1)
> log_success(2)
SUCCESS [2023-01-19 13:53:05] 2
> log_warn(3)
WARN [2023-01-19 13:53:08] 3
Unfortunately this doesn't work because log_success
retrieves SUCCESS
from the logger
namespace:
library(logger)
SUCCESS <- structure(250L, level = 'SUCCESS', class = c('loglevel', 'integer'))
log_threshold(SUCCESS)
log_warn("abc") # this should not emit anything and does not emit anything
log_success("abc") # however this also does not emit anything because logger::SUCCESS is 350
log_error("abc") # this works of course
See the above code chunk: I've overwritten log_success
as well -- that doesn't do the trick in your use case?
If desired I could work on a PR that checks for options(logger.levels)
and uses levels from there if provided
Oh I oversaw that. That could work for me, yes. It's not super elegant but if I'm an isolated case I can live with it
I'm not opposed to introducing an option
for the log levels, but IMO that should be then a bit more general and not only tweaking the integers of the existing labels, but maybe take arbitrarily named int vector? So I think that would require a bit of specification -- I am definitely open to suggestions.
Seems like the above suggestion worked, so closing this ticket. Please reopen if there's interest in customizing log levels.
I would like to show SUCCESS, ERROR and FATAL but not WARN.
This could be achieved in different ways: 1) instead of a
log_threshold
, a possibility to setlog_select_levels
or such 2) providing a way to customize the log level order, e.g. setting SUCCESS to level 250I don't see much of a usecase for changing level order of the standard log4j levels, but IMO the position of SUCCESS is debatable; for me SUCCESS is higher than WARN. I also think implementing (2) would be much slimmer than implementing (1).