Closed orjan closed 6 years ago
To get logging working better with proto.actor integrated into a project using slf4j, I've been adding a companion object into classes and using slf4j for logging. For example:
companion object {
private val LOGGER = LoggerFactory.getLogger(DefaultMailbox::class.java)
}
and then
LOGGER.info("User mailbox count " + userCount)
However there are maybe better solution for kotlin, such as https://github.com/MicroUtils/kotlin-logging which would remove some of the boilerplate, allowing this:
companion object: KLogging()
logger.debug { "Some $expensive message!" }
Any views on whether using slf4j directly, or via a kotlin wrapper library is preferable?
Dependency wise it looks pretty clear: http://search.maven.org/#artifactdetails%7Cio.github.microutils%7Ckotlin-logging%7C1.5.3%7Cjar
I think as a rule of thumb we should a little defensive on the dependencies we pull in so we're not getting issues with transitive dependencies. But if the code will be more clear with the lib above and you'll need to reimplement other stuff otherwise, bring it in. The amount of logs today is relative small so ripping it out in the future is not a big deal.
Focus on removing the println:s from the production code and we can tackle the logging in the tests as a separate PR.
// Örjan
On Sun, Feb 4, 2018 at 3:47 PM, james-cobb notifications@github.com wrote:
To get logging working better with proto.actor integrated into a project using slf4j, I've been adding a companion object into classes and using slf4j for logging. For example:
companion object { private val LOGGER = LoggerFactory.getLogger(DefaultMailbox::class.java) }
and then
LOGGER.info("User mailbox count " + userCount)
However there are maybe better solution for kotlin, such as https://github.com/MicroUtils/kotlin-logging which would remove some of the boilerplate, allowing this:
companion object: KLogging() logger.debug { "Some $expensive message!" }
Any views on whether using slf4j directly, or via a kotlin wrapper library is preferable?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AsynkronIT/protoactor-kotlin/issues/34#issuecomment-362911858, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHkgPdqzQx2cbapNC0Pv6wnSY9rE79_ks5tRcMAgaJpZM4R4fxw .
-- Örjan Sjöholm 0727 - 130037
I think kotlin-logging looks nice, so I've used that for now. In particular removing the requirement to paste the classname into the LoggerFactory is an improvement - failing to cut and paste correctly has caught me out in Java slf4j logs before....
Branch is here: https://github.com/crowdconnected/protoactor-kotlin/tree/issue-34-slf4j which catches all println in the production code.
I'll do another check through the changes before making a PR
James
@james-cobb great work!
Resolved by #36
At the moment we're using println, that makes it hard to control the log-levels