oshai/kotlin-logging

underlyingLogger got a lot more complex

2x2xplz opened this issue · 5 comments

Hi I attempted to upgrade from v3 to v5, my program is relatively simple with just a single global logger instance val logger = KotlinLogging.logger {} and log4j2 underneath, and the one line I use in main() to set the logging level could no longer be compiled:

Configurator.setLevel(logger.underlyingLogger.name, Level.DEBUG)

From what I could tell from the wiki, adjusting the log level is now quite a bit more complicated:

var slf4jLogger get() = (logger as DelegatingKLogger<org.slf4j.Logger>).underlyingLogger
var logbackLogger get() = (slf4jLogger.underlyingLogger) as ch.qos.logback.classic.Logger
var io.github.oshai.kotlinlogging.KLogger.level
    get() = logbackLogger.level
    set(value) { logbackLogger.level = value }

logger.level = Level.DEBUG

Is there any way to get the package to recognize the type of the underlying logger so we could avoid two separate casts? Or to be able to set the level with just a single command like with v3? I greatly appreciate the attempt to provide a Kotlin-esque logging library but the added complexity this package adds (to an already very complex situation) is making me, and I'm sure others, seek an alternative solution. Thank you.

Thank you for reporting an issue. See the wiki for documentation and slack for questions.

oshai commented

We can definitely move that complexity to the lib itself. But for your case, why not just use the following:

Configurator.setLevel(logger.name, Level.DEBUG)

As the name just passed as is between the loggers in different layers, I don't see a reason not to use the name of the logger itself.
Any other solution in the lib itself will still require a cast, as with MPP, not all platforms has the concept of underlyingLogger which is why this interface exists.

Thanks for the quick reply, yes this indeed appears to work. Perhaps this could be added to the docs? That code that required underlyingLogger in v3 may not need it anymore in v5? Honestly I would never have thought to simply remove the underlyingLogger, if it was necessary in v3 I just assumed it was necessary in v5, and the code block above from the wiki seems to support that by continuing to require underlyingLogger.

oshai commented

I suspect that in V3 underlyingLogger is also not required in this case.

Is there still an issue here?