Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

underlyingLogger got a lot more complex #349

Open
2x2xplz opened this issue Aug 9, 2023 · 5 comments
Open

underlyingLogger got a lot more complex #349

2x2xplz opened this issue Aug 9, 2023 · 5 comments

Comments

@2x2xplz
Copy link

2x2xplz commented Aug 9, 2023

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.

@github-actions
Copy link

github-actions bot commented Aug 9, 2023

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

@oshai
Copy link
Owner

oshai commented Aug 9, 2023

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.

@2x2xplz
Copy link
Author

2x2xplz commented Aug 9, 2023

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
Copy link
Owner

oshai commented Aug 10, 2023

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

@oshai
Copy link
Owner

oshai commented Apr 14, 2024

Is there still an issue here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants