Convenient Kotlin LoggerFactory simplification

Question

What is the most convenient way to use SLF4J or other logging approaches with kotlin?

Usually the developer is busy with boilerplate code like

private val logger: Logger = LoggerFactory.getLogger(this::class.java)

in each and every class to get a proper logger?

What are the most convenient ways to unify/simplify this with Kotlin?

s1m0nw1 · Answer 1 · 2018-01-03T10:50:39.740

3

You can define an extension property on every type:

val <T : Any> T.logger: Logger
    get() = LoggerFactory.getLogger(this::class.java)

use it as follows:

class X {
    init {
        logger.debug("init")
    }
}

edited Jan 03 '18 at 10:50

answered Jan 02 '18 at 12:52

s1m0nw1

76,759
17
167
196

1

Ah interesting. Is this also possible with a lazy property to avoid the `getLogger` lookup each time? – Martin Mlostek Jan 02 '18 at 12:54
Unfortunately, you cannot access `this` in lazy. I will try to implement a quick alternative – s1m0nw1 Jan 02 '18 at 12:56
Ok, here you go – s1m0nw1 Jan 02 '18 at 13:11
1

okay, this is brilliant. does this approach have any side effects / performance impact / memory footprint increase on classes which never use the logger? (because its an extension to all types)? – Martin Mlostek Jan 02 '18 at 14:30
No you can use it unhesitatingly:) – s1m0nw1 Jan 02 '18 at 14:53
1

I found a major bug in the lazy solution, since extensions are resolved statically, there was always the same logger used, i.e. not one logger per class. I've removed the lazy stuff until I come up with a better solution. – s1m0nw1 Jan 03 '18 at 10:52
thanks for letting me know. curious what you will come up with :) – Martin Mlostek Jan 03 '18 at 11:08
@s1m0w1 did you have the heureka moment alredy? – Martin Mlostek Jan 04 '18 at 19:15
No I’m sorry, could not find an alternative yet. I’d be interested which solution you are using currently? – s1m0nw1 Jan 05 '18 at 18:49
I am currently having one logger val per class/companion – Martin Mlostek Jan 10 '18 at 20:47

score 2 · Answer 2 · answered Jan 02 '18 at 13:17

I define this function in my projects to make defining a logger easier for me. It takes advantage of Kotlin's reified types.

// Defined in Utilities.kt
inline fun <reified T:Any> logFor() =
    LoggerFactory.getLogger(T::class.java)

Usage:

class MyClass {
    private val log = logFor<MyClass>()
    ...
 }

Or if you are creating a lot of them:

class MyClass {
    companion object {
        private val log = logFor<MyClass>()
    }
    ...
}

Preston Garno · Accepted Answer · 2018-01-02T15:57:00.207

Here's a simple example which returns a lazily-initialized logger from a bound callable reference or a standard property. I prefer calling from a callable reference because the :: denotes reflection (related to logging).

The class which provides the Lazy<Logger>:

class LoggingProvider<T : Any>(val clazz: KClass<T>) {

  operator fun provideDelegate(inst: Any?, property: KProperty<*>) =
      lazy { LoggerFactory.getLogger(clazz.java) }
}

Inline functions to call them:

inline fun <reified T : Any> KCallable<T>.logger() = 
  LoggingProvider(T::class)

inline fun <reified T : Any> T.logger() = 
  LoggingProvider(T::class)

Here's an example of using them. The require assertion in the initializer shows that the loggers share a reference:

class Foo {

  val self: Foo = this

  val logger by this.logger()
  val callableLogger by this::self.logger()

  init {
    require(logger === callableLogger)
  }

}

score 0 · Answer 4 · answered Jan 02 '18 at 11:21

0

if you don't like the boilerplate, you can always wrap the log.info with your own logger helper:

mylog.info(this, "data that needs to be logged")

Then in the background, have some sort of hashmap that keeps track of classes of the this param that can instantiate a logger for that class.

Other options might be using AspectJ Weaving to weave a logger into each class, but this is overkill in my opinion.

answered Jan 02 '18 at 11:21

Jan Vladimir Mostert

12,380
15
80
137

that is what i already tried. But I would even like to kill the redundant call `Log.X(this, ...)`... thinking of inlining like in c/c++ . And in this case I want to stick to the SLF4J approach – Martin Mlostek Jan 02 '18 at 11:23
AspectJ can do this for you, but you will need to setup your application to support compile-time AspectJ Weaving. Personally I would rather use the boilerplate than go the AspectJ route. Here's a good introduction: https://blog.jayway.com/2015/09/03/aspectj-and-aop-the-black-magic-of-programming/ – Jan Vladimir Mostert Jan 02 '18 at 11:28
What are the reasons you wouldn't go with AspectJ? – Martin Mlostek Jan 02 '18 at 12:29
It adds a lot of complexity to your build process (you'll need to add a precompile step that weaves in the Aspects and this might fail sometimes or certain aspects might not weave in due to misconfiguration), you need an IDE that supports AspectJ Weaving, otherwise you will just get red squiggles under everything and you'll need to learn a new "language" in order to write these aspects. Maybe try it out and see how much work it is to setup, it'll just be a once-off thing you have to write. – Jan Vladimir Mostert Jan 02 '18 at 12:36

score -2 · Answer 5 · answered Jan 02 '18 at 12:27

I have defined a utility method for this

fun getLogger(cl: KClass<*>): Logger {
    return LoggerFactory.getLogger(cl.java)!!
}

and now in each class I can use the logger like this

companion object {
    private val logger = getLogger(MyClass::class)
}

Convenient Kotlin LoggerFactory simplification

5 Answers5