-
-
Notifications
You must be signed in to change notification settings - Fork 116
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
Comments
Thank you for reporting an issue. See the wiki for documentation and slack for questions. |
We can definitely move that complexity to the lib itself. But for your case, why not just use the following:
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. |
Thanks for the quick reply, yes this indeed appears to work. Perhaps this could be added to the docs? That code that required |
I suspect that in V3 |
Is there still an issue here? |
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 inmain()
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:
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.
The text was updated successfully, but these errors were encountered: