Deprecate and remove LoggerConfig class from open-source Flogger
hagbard opened this issue · comments
The LoggerConfig class needs to be removed from the main Flogger artifact.
This class is confusing because it implies it configures Flogger behaviour, when in fact it's just a helper for the JDK logger and has no dependency on Flogger at all. It should be removed from the com.google.common.flogger package (though I'm not against it turning up as its own artifact if people really want it, but I'm inclined to just say "that's someone else's job if they want it").
I have no visibility into the uses of this class outside Google, so I'm inclined to just make a breaking release (allowed since Flogger is 0.x and makes no API stability promises) and see if anyone shouts. Not ideal, but the alternative is having a protracted deprecation period for probably no benefit. I'll do one release with it marked to removal and then in about 2 weeks it'll go away.
All anyone needs to do is copy the one class to a different package in their code and fixup callers.
I am usingLoggerConfig to create kotlin DSL https://github.com/xmlking/micro-apps/blob/develop/libs/core/src/main/kotlin/micro/apps/core/util/LogDefinition.kt
Intended to use like this : https://github.com/xmlking/micro-apps/blob/develop/libs/core/src/test/kotlin/micro/apps/core/util/LogTest.kt#L9
The mechanism for how to control logging is a function of the backend you choose (JDK, Log4J etc.). This is why the LoggerConfig class is bad and being removed (it only works for the JDK logger).
So for now, since I don't have the time to figure out a generic API for logging configuration that works for all potential backends, I'd recommend either:
(a) doing logging configuration by using properties files and whatever data based mechanism your backend supports.
(b) use programmatic configuration (according to the chosen backend) it the main entry point of your tool (if it doesn't have access to settings files).
Basically telling you how to configure logging is out of scope for the Flogger API itself.
Personally I think that any programmatic logging configuration inside libraries is to be treated with suspicion (though tests might be a special case where a helper library can be useful).
It also looks like you're using a very old version of Flogger (there is no "config()" method on the API now).
https://github.com/google/flogger/blob/master/api/src/main/java/com/google/common/flogger/FluentLogger.java
@hagbard Just a note:, I am creating Kotlin extensions for flogger to make it easy (one-liner) for Kotlin users. for example with my extension developers can use:
since i added config() extension on FluentLogger, you see this method.
For kotlin
private var logger: FluentLogger = FluentLogger.forEnclosingClass().config(Level.ALL)
// or
private var logger: FluentLogger = FluentLogger.forEnclosingClass().config()For Java
private static final FluentLogger logger = LogDefinition.Companion.jConfig(FluentLogger.forEnclosingClass());otherwise Kotlin users have to use companion objects to declare static variables, which is verbose then java
without my extension , verbose way of using flogger in kotlin looks like this
import com.google.common.flogger.FluentLogger
class MyClass {
companion object {
private val logger by lazy { FluentLogger.forEnclosingClass() }
}
// or
companion object {
@JvmStatic private val log = FluentLogger.forEnclosingClass()
}
fun main() {
log.atWarning().log("test warn")
}
updated test cases to show you the usage: please take a look, how I am using the flogger API
Extention:
Kotlin test case to demonstrate Kotlin usage:
Kotlin test case to demonstrate java usage:
The mechanism for how to control logging is a function of the backend you choose (JDK, Log4J etc.). This is why the
LoggerConfigclass is bad and being removed (it only works for the JDK logger).So for now, since I don't have the time to figure out a generic API for logging configuration that works for all potential backends, I'd recommend either:
(a) doing logging configuration by using properties files and whatever data based mechanism your backend supports.
(b) use programmatic configuration (according to the chosen backend) it the main entry point of your tool (if it doesn't have access to settings files).Basically telling you how to configure logging is out of scope for the Flogger API itself.
Personally I think that any programmatic logging configuration inside libraries is to be treated with suspicion (though tests might be a special case where a helper library can be useful).
Setting log level is not important for me, but to create Kotlin extension, I need LoggerConfig.of() API
Yeah, the "of()" method is exactly the problematic API that I'm getting rid of. It returns what is essentially just a wrapped JDK logger under the hood, which is useless if you're using Log4J etc.
Sorry for adding it and giving people the impression it would work in the general case :(
In fact even having a "change the log level of this logger" is problematic, because there's no reason that many classes couldn't share the same logger instance (depending on the backend chosen). I deliberately named the method "forEnclosingClass()" so that in future a backend could say "well, the right logger for all classes is this one singleton" and then there cannot be any "per class" logging configuration like this.
I think you might just have to accept that controlling logging on a per logger basis is very much tied to choosing a specific backend implementation, and as such it's not something you can support in the general API.
@hagbard agree your point. I will follow the new recommendations.
Really appreciate design and thinking your guys putting behind flogger, to make it truly zero cost logger.
please consider kotlin users when designing Flogger API, because there is no good pragmatic logger for kotlin :(
the reason I like to use Flogger is, for 1. Structured logging (context) 2. zero cost when log level is disabled.
I'm glad you're finding Flogger useful, and sorry for the slow responses here; I'll try and do better in the future.
I don't know much about Kotlin myself, but there have been long discussions about it at Google (and it is supported for Kotlin in Google). There were discussions about adding Kotlin friendly API extensions, but I think in the end it was decided that the complexity outweighed the benefit.
It means Flogger isn't fully idiomatic for Kotlin's style, but at the same time we definitely won't be making it "incompatible" with Kotlin at any point (i.e. all new API changes are being considered with respect to both Java and Kotlin).