Kotlin nie ma takiego samego pojęcia o polach statycznych, jak używane w Javie. W Javie ogólnie przyjęty sposób rejestrowania to:

public class Foo {
    private static final Logger LOG = LoggerFactory.getLogger(Foo.class);
}

Pytanie brzmi, jaki jest idiomatyczny sposób wykonywania logowania w Kotlinie?

W większości dojrzałego kodu Kotlin poniżej znajdziesz jeden z tych wzorców. Podejście wykorzystujące delegatów właściwości wykorzystuje moc Kotlin do tworzenia najmniejszego kodu.

Uwaga: kod tutaj jest przeznaczony, java.util.Loggingale ta sama teoria dotyczy każdej biblioteki rejestrowania

Statyczne (typowe, odpowiednik twojego kodu Java w pytaniu)

Jeśli nie możesz ufać wydajności tego wyszukiwania skrótu w systemie rejestrowania, możesz uzyskać podobne zachowanie do kodu Java, używając obiektu towarzyszącego, który może przechowywać instancję i sprawiać wrażenie statycznego.

class MyClass {
    companion object {
        val LOG = Logger.getLogger(MyClass::class.java.name) 
    }

    fun foo() {
        LOG.warning("Hello from MyClass")
    }
}  

tworzenie wyników:

26 grudnia 2015 11:28:32 org.stackoverflow.kotlin.test.MyClassfoo INFO: Witam z MyClass

Więcej o obiektach towarzyszących tutaj: Obiekty towarzyszące ... Zauważ również, że w powyższym przykładzie MyClass::class.javapobiera instancję typu Class<MyClass>dla rejestrującego, podczas gdy this.javaClasspobiera instancję typu Class<MyClass.Companion>.

Na wystąpienie klasy (wspólne)

Ale naprawdę nie ma powodu, aby unikać wywoływania i pobierania programu rejestrującego na poziomie instancji. Wspomniany przez ciebie idiomatyczny sposób w Javie jest przestarzały i opiera się na strachu przed wydajnością, podczas gdy rejestrator dla każdej klasy jest już buforowany przez prawie każdy rozsądny system logowania na świecie. Po prostu utwórz członka do przechowywania obiektu rejestrującego.

class MyClass {
  val LOG = Logger.getLogger(this.javaClass.name)

  fun foo() {
        LOG.warning("Hello from MyClass")
  }
} 

tworzenie wyników:

26 grudnia 2015 11:28:44 org.stackoverflow.kotlin.test.MyClass foo INFO: Witam z MyClass

Możesz przetestować wydajność zarówno dla instancji, jak i odmian klas, i sprawdzić, czy istnieje realistyczna różnica w przypadku większości aplikacji.

Delegaci nieruchomości (zwykli, najbardziej eleganccy)

Innym podejściem, które sugeruje @Jire w innej odpowiedzi, jest utworzenie delegata właściwości, którego można następnie użyć do jednolitego wykonywania logiki w dowolnej innej klasie, którą chcesz. Jest na to prostszy sposób, ponieważ Kotlin już dostarcza Lazydelegata, możemy po prostu opakować go w funkcję. Jedna sztuczka polega na tym, że jeśli chcemy poznać typ klasy aktualnie używającej delegata, robimy z tego funkcję rozszerzającą dla dowolnej klasy:

fun <R : Any> R.logger(): Lazy<Logger> {
    return lazy { Logger.getLogger(unwrapCompanionClass(this.javaClass).name) }
}
// see code for unwrapCompanionClass() below in "Putting it all Together section"

Ten kod zapewnia również, że jeśli użyjesz go w obiekcie towarzyszącym, nazwa programu rejestrującego będzie taka sama, jak w przypadku użycia jej w samej klasie. Teraz możesz po prostu:

class Something {
    val LOG by logger()

    fun foo() {
        LOG.info("Hello from Something")
    }
}

dla instancji klasy lub jeśli chcesz, aby była bardziej statyczna z jedną instancją na klasę:

class SomethingElse {
    companion object {
        val LOG by logger()

    }

    fun foo() {
        LOG.info("Hello from SomethingElse")
    }
}

Wynik wywołania foo()obu tych klas byłby następujący:

26 grudnia 2015 11:30:55 org.stackoverflow.kotlin.test.Something foo INFO: Hello from Something

26 grudnia 2015 11:30:55 org.stackoverflow.kotlin.test.SomethingElse foo INFO: Hello from SomethingElse

Funkcje rozszerzające (rzadkie w tym przypadku z powodu „zanieczyszczenia” dowolnej przestrzeni nazw)

Kotlin ma kilka ukrytych sztuczek, które pozwalają jeszcze zmniejszyć część tego kodu. Możesz tworzyć funkcje rozszerzające na klasach i tym samym nadawać im dodatkową funkcjonalność. Jedna sugestia w komentarzach powyżej dotyczyła rozszerzenia Anyo funkcję rejestratora. Może to powodować szum za każdym razem, gdy ktoś używa uzupełniania kodu w swoim IDE w dowolnej klasie. Ale jest sekretna korzyść z rozszerzenia Anylub innego interfejsu znaczników: możesz zasugerować, że rozszerzasz swoją własną klasę, a tym samym wykryć klasę, w której się znajdujesz. Co? Aby być mniej zagmatwanym, oto kod:

// extend any class with the ability to get a logger
fun <T: Any> T.logger(): Logger {
     return Logger.getLogger(unwrapCompanionClass(this.javaClass).name)
}

Teraz w klasie (lub obiekcie towarzyszącym) mogę po prostu wywołać to rozszerzenie w mojej własnej klasie:

class SomethingDifferent {
    val LOG = logger()

    fun foo() {
        LOG.info("Hello from SomethingDifferent")
    }
}

Produkcja wyników:

26 grudnia 2015 11:29:12 org.stackoverflow.kotlin.test.SomethingDifferent foo INFO: Hello from SomethingDifferent

Zasadniczo kod jest postrzegany jako wezwanie do rozszerzenia Something.logger(). Problem polega na tym, że poniższe mogą również być prawdziwe, powodując „zanieczyszczenie” innych klas:

val LOG1 = "".logger()
val LOG2 = Date().logger()
val LOG3 = 123.logger()

Funkcje rozszerzeń w interfejsie znacznika (nie wiem, jak często, ale wspólny model dla „cech”)

Aby ułatwić korzystanie z rozszerzeń i zmniejszyć „zanieczyszczenie”, możesz użyć interfejsu znaczników, aby rozszerzyć:

interface Loggable {} 

fun Loggable.logger(): Logger {
     return Logger.getLogger(unwrapCompanionClass(this.javaClass).name)
}    

Lub nawet uczyń metodę częścią interfejsu z domyślną implementacją:

interface Loggable {
    public fun logger(): Logger {
        return Logger.getLogger(unwrapCompanionClass(this.javaClass).name)
    }
}

I użyj jednej z tych odmian w swojej klasie:

class MarkedClass: Loggable {
    val LOG = logger()
}

Produkcja wyników:

26 grudnia 2015 11:41:01 org.stackoverflow.kotlin.test.MarkedClass foo INFO: Witam z MarkedClass

Jeśli chciałbyś wymusić utworzenie jednolitego pola do przechowywania loggera, to korzystając z tego interfejsu możesz łatwo wymagać od realizatora posiadania pola takiego jak LOG:

interface Loggable {
    val LOG: Logger  // abstract required field

    public fun logger(): Logger {
        return Logger.getLogger(unwrapCompanionClass(this.javaClass).name)
    }
}

Teraz implementator interfejsu musi wyglądać tak:

class MarkedClass: Loggable {
    override val LOG: Logger = logger()
}

Oczywiście abstrakcyjna klasa bazowa może zrobić to samo, mając opcję zarówno interfejsu, jak i klasy abstrakcyjnej implementującej ten interfejs, co zapewnia elastyczność i jednolitość:

abstract class WithLogging: Loggable {
    override val LOG: Logger = logger()
}

// using the logging from the base class
class MyClass1: WithLogging() {
    // ... already has logging!
}

// providing own logging compatible with marker interface
class MyClass2: ImportantBaseClass(), Loggable {
    // ... has logging that we can understand, but doesn't change my hierarchy
    override val LOG: Logger = logger()
}

// providing logging from the base class via a companion object so our class hierarchy is not affected
class MyClass3: ImportantBaseClass() {
    companion object : WithLogging() {
       // we have the LOG property now!
    }
}

Kładąc wszystko razem (mała biblioteka pomocnicza)

Oto mała biblioteka pomocnicza, dzięki której każda z powyższych opcji jest łatwa w użyciu. Kotlin często rozszerza API, aby bardziej odpowiadały Twoim upodobaniom. Albo w rozszerzeniu, albo w funkcjach najwyższego poziomu. Oto zestawienie opcji tworzenia rejestratorów oraz próbka pokazująca wszystkie odmiany:

// Return logger for Java class, if companion object fix the name
fun <T: Any> logger(forClass: Class<T>): Logger {
    return Logger.getLogger(unwrapCompanionClass(forClass).name)
}

// unwrap companion class to enclosing class given a Java Class
fun <T : Any> unwrapCompanionClass(ofClass: Class<T>): Class<*> { 
   return ofClass.enclosingClass?.takeIf { 
      ofClass.enclosingClass.kotlin.companionObject?.java == ofClass 
   } ?: ofClass 
}

// unwrap companion class to enclosing class given a Kotlin Class
fun <T: Any> unwrapCompanionClass(ofClass: KClass<T>): KClass<*> {
   return unwrapCompanionClass(ofClass.java).kotlin
}

// Return logger for Kotlin class
fun <T: Any> logger(forClass: KClass<T>): Logger {
    return logger(forClass.java)
}

// return logger from extended class (or the enclosing class)
fun <T: Any> T.logger(): Logger {
    return logger(this.javaClass)
}

// return a lazy logger property delegate for enclosing class
fun <R : Any> R.lazyLogger(): Lazy<Logger> {
    return lazy { logger(this.javaClass) }
}

// return a logger property delegate for enclosing class
fun <R : Any> R.injectLogger(): Lazy<Logger> {
    return lazyOf(logger(this.javaClass))
}

// marker interface and related extension (remove extension for Any.logger() in favour of this)
interface Loggable {}
fun Loggable.logger(): Logger = logger(this.javaClass)

// abstract base class to provide logging, intended for companion objects more than classes but works for either
abstract class WithLogging: Loggable {
    val LOG = logger()
}

Wybierz jedną z tych, które chcesz zachować, a oto wszystkie używane opcje:

class MixedBagOfTricks {
    companion object {
        val LOG1 by lazyLogger()          // lazy delegate, 1 instance per class
        val LOG2 by injectLogger()        // immediate, 1 instance per class
        val LOG3 = logger()               // immediate, 1 instance per class
        val LOG4 = logger(this.javaClass) // immediate, 1 instance per class
    }

    val LOG5 by lazyLogger()              // lazy delegate, 1 per instance of class
    val LOG6 by injectLogger()            // immediate, 1 per instance of class
    val LOG7 = logger()                   // immediate, 1 per instance of class
    val LOG8 = logger(this.javaClass)     // immediate, 1 instance per class
}

val LOG9 = logger(MixedBagOfTricks::class)  // top level variable in package

// or alternative for marker interface in class
class MixedBagOfTricks : Loggable {
    val LOG10 = logger()
}

// or alternative for marker interface in companion object of class
class MixedBagOfTricks {
    companion object : Loggable {
        val LOG11 = logger()
    }
}

// or alternative for abstract base class for companion object of class
class MixedBagOfTricks {
    companion object: WithLogging() {} // instance 12

    fun foo() {
       LOG.info("Hello from MixedBagOfTricks")
    }
}

// or alternative for abstract base class for our actual class
class MixedBagOfTricks : WithLogging() { // instance 13
    fun foo() {
       LOG.info("Hello from MixedBagOfTricks")
    }
}

Wszystkie 13 wystąpień rejestratorów utworzonych w tym przykładzie będzie generować tę samą nazwę programu rejestrującego i dane wyjściowe:

26 grudnia 2015 11:39:00 org.stackoverflow.kotlin.test.MixedBagOfTricks foo INFO: Witam z MixedBagOfTricks

Uwaga: Do unwrapCompanionClass()metoda gwarantuje, że nie generują rejestratora po nazwie obiektu towarzyszącego ale raczej klasy okalającego. Jest to obecnie zalecany sposób znajdowania klasy zawierającej obiekt towarzyszący. Usunięcie „ $ Companion ” z nazwy za pomocą removeSuffix()nie działa, ponieważ obiektom towarzyszącym można nadawać niestandardowe nazwy.

Spójrz na bibliotekę rejestrującą kotlin .
Umożliwia takie logowanie:

private val logger = KotlinLogging.logger {}

class Foo {
  logger.info{"wohoooo $wohoooo"}
}

Lub tak:

class FooWithLogging {
  companion object: KLogging()
  fun bar() {
    logger.info{"wohoooo $wohoooo"}
  }
}

Napisałem również wpis na blogu, porównując go z AnkoLogger: Logowanie się w Kotlin i Androidzie: AnkoLogger vs kotlin-logging

Zastrzeżenie: jestem opiekunem tej biblioteki.

Edycja: logowanie kotlin ma teraz obsługę wielu platform: https://github.com/MicroUtils/kotlin-logging/wiki/Multiplatform-support

Jako dobry przykład implementacji logowania chciałbym wspomnieć o Anko, która używa specjalnego interfejsu, AnkoLoggerktóry klasa wymagająca logowania powinna zaimplementować. W interfejsie znajduje się kod, który generuje tag rejestrowania dla klasy. Rejestrowanie odbywa się następnie za pomocą funkcji rozszerzających, które można wywołać w ramach implementacji interfejsu bez prefiksów, a nawet tworzenia instancji rejestratora.

Nie sądzę, że jest to idiomatyczne , ale wydaje się dobrym podejściem, ponieważ wymaga minimalnego kodu, wystarczy dodać interfejs do deklaracji klasy, a otrzymasz rejestrowanie z różnymi tagami dla różnych klas.

Po pierwsze, istnieje interfejs, który zachowuje się jak interfejs znaczników:

interface MyLogger {
    val tag: String get() = javaClass.simpleName
}

Pozwala jej implementacji na użycie funkcji rozszerzeń MyLoggerwewnątrz ich kodu, po prostu je wywołując this. Zawiera również tag logowania.

Następnie znajduje się ogólny punkt wejścia dla różnych metod logowania:

private inline fun log(logger: MyLogger,
                       message: Any?,
                       throwable: Throwable?,
                       level: Int,
                       handler: (String, String) -> Unit,
                       throwableHandler: (String, String, Throwable) -> Unit
) {
    val tag = logger.tag
    if (isLoggingEnabled(tag, level)) {
        val messageString = message?.toString() ?: "null"
        if (throwable != null)
            throwableHandler(tag, messageString, throwable)
        else
            handler(tag, messageString)
    }
}

Zostanie wywołany przez metody logowania. Pobiera tag z MyLoggerimplementacji, sprawdza ustawienia rejestrowania, a następnie wywołuje jeden z dwóch programów obsługi, ten z Throwableargumentem, a drugi bez.

Następnie możesz zdefiniować dowolną liczbę metod logowania, w ten sposób:

fun MyLogger.info(message: Any?, throwable: Throwable? = null) =
        log(this, message, throwable, LoggingLevels.INFO,
            { tag, message -> println("INFO: $tag # $message") },
            { tag, message, thr -> 
                println("INFO: $tag # $message # $throwable");
                thr.printStackTrace()
            })

Są one definiowane tylko raz w celu rejestrowania tylko wiadomości i logowania Throwable, jest to wykonywane z opcjąthrowable parametru.

Funkcje, które są przekazywane jako handleri throwableHandlermogą być różne dla różnych metod rejestrowania, na przykład mogą zapisać dziennik do pliku lub przesłać go gdzieś. isLoggingEnabledi LoggingLevelssą pomijane dla zwięzłości, ale ich używanie zapewnia jeszcze większą elastyczność.

class MyClass : MyLogger {
    fun myFun() {
        info("Info message")
    }
}

Jest mała wada: do logowania do funkcji na poziomie pakietu potrzebny będzie obiekt rejestrujący:

private object MyPackageLog : MyLogger

fun myFun() {
    MyPackageLog.info("Info message")
}

KISS: Dla zespołów Java przenoszących się do Kotlin

Jeśli nie masz nic przeciwko podawaniu nazwy klasy przy każdej instancji programu rejestrującego (tak jak java), możesz to uprościć, definiując to jako funkcję najwyższego poziomu gdzieś w swoim projekcie:

import org.slf4j.LoggerFactory

inline fun <reified T:Any> logger() = LoggerFactory.getLogger(T::class.java)

Używa parametru typu reified Kotlin .

Teraz możesz użyć tego w następujący sposób:

class SomeClass {
  // or within a companion object for one-instance-per-class
  val log = logger<SomeClass>()
  ...
}

To podejście jest super proste i zbliżone do odpowiednika w Javie, ale dodaje tylko trochę cukru składniowego.

Następny krok: rozszerzenia lub pełnomocnicy

Osobiście wolę pójść o krok dalej i zastosować podejście rozszerzeń lub delegatów. Jest to ładnie podsumowane w odpowiedzi @ JaysonMinard, ale tutaj jest TL; DR dla podejścia „delegata” z log4j2 API ( AKTUALIZACJA : nie ma już potrzeby ręcznego pisania tego kodu, ponieważ został wydany jako oficjalny moduł projekt log4j2, patrz poniżej). Ponieważ log4j2, w przeciwieństwie do slf4j, obsługuje logowanie za pomocą Supplier, dodałem również delegata, aby ułatwić korzystanie z tych metod.

import org.apache.logging.log4j.LogManager
import org.apache.logging.log4j.Logger
import org.apache.logging.log4j.util.Supplier
import kotlin.reflect.companionObject

/**
 * An adapter to allow cleaner syntax when calling a logger with a Kotlin lambda. Otherwise calling the
 * method with a lambda logs the lambda itself, and not its evaluation. We specify the Lambda SAM type as a log4j2 `Supplier`
 * to avoid this. Since we are using the log4j2 api here, this does not evaluate the lambda if the level
 * is not enabled.
 */
class FunctionalLogger(val log: Logger): Logger by log {
  inline fun debug(crossinline supplier: () -> String) {
    log.debug(Supplier { supplier.invoke() })
  }

  inline fun debug(t: Throwable, crossinline supplier: () -> String) {
    log.debug(Supplier { supplier.invoke() }, t)
  }

  inline fun info(crossinline supplier: () -> String) {
    log.info(Supplier { supplier.invoke() })
  }

  inline fun info(t: Throwable, crossinline supplier: () -> String) {
    log.info(Supplier { supplier.invoke() }, t)
  }

  inline fun warn(crossinline supplier: () -> String) {
    log.warn(Supplier { supplier.invoke() })
  }

  inline fun warn(t: Throwable, crossinline supplier: () -> String) {
    log.warn(Supplier { supplier.invoke() }, t)
  }

  inline fun error(crossinline supplier: () -> String) {
    log.error(Supplier { supplier.invoke() })
  }

  inline fun error(t: Throwable, crossinline supplier: () -> String) {
    log.error(Supplier { supplier.invoke() }, t)
  }
}

/**
 * A delegate-based lazy logger instantiation. Use: `val log by logger()`.
 */
@Suppress("unused")
inline fun <reified T : Any> T.logger(): Lazy<FunctionalLogger> =
  lazy { FunctionalLogger(LogManager.getLogger(unwrapCompanionClass(T::class.java))) }

// unwrap companion class to enclosing class given a Java Class
fun <T : Any> unwrapCompanionClass(ofClass: Class<T>): Class<*> {
  return if (ofClass.enclosingClass != null && ofClass.enclosingClass.kotlin.companionObject?.java == ofClass) {
    ofClass.enclosingClass
  } else {
    ofClass
  }
}

Log4j2 Kotlin Logging API

Większość poprzedniej sekcji została bezpośrednio przystosowana do tworzenia modułu Kotlin Logging API , który jest teraz oficjalną częścią Log4j2 (zastrzeżenie: jestem głównym autorem). Możesz pobrać to bezpośrednio z Apache lub przez Maven Central .

Użycie jest zasadniczo takie, jak opisano powyżej, ale moduł obsługuje zarówno dostęp do rejestratora oparty na interfejsie, funkcję loggerrozszerzającą Anydo użytku w miejscu, w którym thisjest zdefiniowana, jak i nazwaną funkcję rejestrującą do użytku, gdy nie thisjest zdefiniowane (na przykład funkcje najwyższego poziomu).

Anko

Możesz to zrobić za pomocą Ankobiblioteki. Miałbyś kod jak poniżej:

class MyActivity : Activity(), AnkoLogger {
    private fun someMethod() {
        info("This is my first app and it's awesome")
        debug(1234) 
        warn("Warning")
    }
}

logowanie kotlin

Biblioteka kotlin-logging ( projekt Github - kotlin-logging ) umożliwia pisanie kodu do logowania, jak poniżej:

class FooWithLogging {
  companion object: KLogging()
  fun bar() {
    logger.info{"Item $item"}
  }
}

StaticLog

lub możesz również użyć tej małej napisanej w bibliotece Kotlin nazwanej StaticLogwtedy Twój kod będzie wyglądał następująco:

Log.info("This is an info message")
Log.debug("This is a debug message")
Log.warn("This is a warning message","WithACustomTag")
Log.error("This is an error message with an additional Exception for output", "AndACustomTag", exception )

Log.logLevel = LogLevel.WARN
Log.info("This message will not be shown")\

Drugie rozwiązanie może być lepsze, jeśli chcesz zdefiniować format wyjściowy dla metody logowania, taki jak:

Log.newFormat {
    line(date("yyyy-MM-dd HH:mm:ss"), space, level, text("/"), tag, space(2), message, space(2), occurrence)
}

lub użyj filtrów, na przykład:

Log.filterTag = "filterTag"
Log.info("This log will be filtered out", "otherTag")
Log.info("This log has the right tag", "filterTag")

timberkt

Jeśli korzystałeś już z Timberbiblioteki logowania Jake'a Whartona, sprawdź timberkt.

Ta biblioteka opiera się na Timber z interfejsem API, który jest łatwiejszy w użyciu od Kotlin. Zamiast używać parametrów formatowania, przekazujesz lambdę, która jest oceniana tylko wtedy, gdy komunikat jest rejestrowany.

Przykład kodu:

// Standard timber
Timber.d("%d %s", intVar + 3, stringFun())

// Kotlin extensions
Timber.d { "${intVar + 3} ${stringFun()}" }
// or
d { "${intVar + 3} ${stringFun()}" }

Sprawdź również: Logowanie w Kotlin i Android: AnkoLogger vs kotlin-logging

Mam nadzieję, że to pomoże

Czy coś takiego zadziała dla Ciebie?

class LoggerDelegate {

    private var logger: Logger? = null

    operator fun getValue(thisRef: Any?, property: KProperty<*>): Logger {
        if (logger == null) logger = Logger.getLogger(thisRef!!.javaClass.name)
        return logger!!
    }

}

fun logger() = LoggerDelegate()

class Foo { // (by the way, everything in Kotlin is public by default)
    companion object { val logger by logger() }
}

Nie słyszałem o żadnym idiomie w tym zakresie. Im prostsze, tym lepiej, więc użyłbym właściwości najwyższego poziomu

val logger = Logger.getLogger("package_name")

Ta praktyka dobrze sprawdza się w Pythonie i chociaż Kotlin i Python mogą się różnić, wydaje mi się, że są one dość podobne w swoim „duchu” (mówiąc o idiomach).

A co z funkcją rozszerzającą w Class? W ten sposób otrzymasz:

public fun KClass.logger(): Logger = LoggerFactory.getLogger(this.java)

class SomeClass {
    val LOG = SomeClass::class.logger()
}

Uwaga - w ogóle tego nie testowałem, więc może nie być całkiem poprawne.

Po pierwsze, możesz dodać funkcje rozszerzające do tworzenia rejestratora.

inline fun <reified T : Any> getLogger() = LoggerFactory.getLogger(T::class.java)
fun <T : Any> T.getLogger() = LoggerFactory.getLogger(javaClass)

Wtedy będziesz mógł stworzyć rejestrator używając poniższego kodu.

private val logger1 = getLogger<SomeClass>()
private val logger2 = getLogger()

Po drugie, możesz zdefiniować interfejs, który zapewnia rejestrator i jego implementację mieszaną.

interface LoggerAware {
  val logger: Logger
}

class LoggerAwareMixin(containerClass: Class<*>) : LoggerAware {
  override val logger: Logger = LoggerFactory.getLogger(containerClass)
}

inline fun <reified T : Any> loggerAware() = LoggerAwareMixin(T::class.java)

Ten interfejs może być używany w następujący sposób.

class SomeClass : LoggerAware by loggerAware<SomeClass>() {
  // Now you can use a logger here.
}

utwórz obiekt towarzyszący i oznacz odpowiednie pola adnotacją @JvmStatic

Jest tu już wiele świetnych odpowiedzi, ale wszystkie dotyczą dodawania loggera do klasy, ale jak byś to zrobił, aby zarejestrować się w funkcjach najwyższego poziomu?

To podejście jest ogólne i na tyle proste, że działa dobrze w obu klasach, obiektach towarzyszących i funkcjach najwyższego poziomu:

package nieldw.test

import org.apache.logging.log4j.LogManager
import org.apache.logging.log4j.Logger
import org.junit.jupiter.api.Test

fun logger(lambda: () -> Unit): Lazy<Logger> = lazy { LogManager.getLogger(getClassName(lambda.javaClass)) }
private fun <T : Any> getClassName(clazz: Class<T>): String = clazz.name.replace(Regex("""\$.*$"""), "")

val topLog by logger { }

class TopLevelLoggingTest {
    val classLog by logger { }

    @Test
    fun `What is the javaClass?`() {
        topLog.info("THIS IS IT")
        classLog.info("THIS IS IT")
    }
}

Generalnie do tego służą obiekty towarzyszące: zastępowanie statycznych elementów.

Przykład Slf4j, to samo dla innych. Działa to nawet przy tworzeniu rejestratora na poziomie pakietu

/**  
  * Get logger by current class name.  
  */ 

fun getLogger(c: () -> Unit): Logger = 
        LoggerFactory.getLogger(c.javaClass.enclosingClass)

Stosowanie:

val logger = getLogger { }

fun <R : Any> R.logger(): Lazy<Logger> = lazy { 
    LoggerFactory.getLogger((if (javaClass.kotlin.isCompanion) javaClass.enclosingClass else javaClass).name) 
}

class Foo {
    val logger by logger()
}

class Foo {
    companion object {
        val logger by logger()
    }
}

To wciąż WIP (prawie ukończone), więc chciałbym się nim podzielić: https://github.com/leandronunes85/log-format-enforcer#kotlin-soon-to-come-in-version-14

Głównym celem tej biblioteki jest wymuszenie określonego stylu dziennika w całym projekcie. Poprzez wygenerowanie kodu Kotlin próbuję rozwiązać niektóre z problemów wymienionych w tym pytaniu. Jeśli chodzi o pierwotne pytanie, zwykle robię po prostu:

private val LOG = LogFormatEnforcer.loggerFor<Foo>()
class Foo {

}

Możesz po prostu zbudować własną „bibliotekę” narzędzi. Nie potrzebujesz dużej biblioteki do tego zadania, co sprawi, że Twój projekt będzie cięższy i złożony.

Na przykład, możesz użyć Kotlin Reflection, aby uzyskać nazwę, typ i wartość dowolnej właściwości klasy.

Przede wszystkim upewnij się, że meta-zależność została ustalona w pliku build.gradle:

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-reflect:$kotlin_version"
}

Następnie możesz po prostu skopiować i wkleić ten kod do swojego projektu:

import kotlin.reflect.full.declaredMemberProperties

class LogUtil {
    companion object {
        /**
         * Receives an [instance] of a class.
         * @return the name and value of any member property.
         */
        fun classToString(instance: Any): String {
            val sb = StringBuilder()

            val clazz = instance.javaClass.kotlin
            clazz.declaredMemberProperties.forEach {
                sb.append("${it.name}: (${it.returnType}) ${it.get(instance)}, ")
            }

            return marshalObj(sb)
        }

        private fun marshalObj(sb: StringBuilder): String {
            sb.insert(0, "{ ")
            sb.setLength(sb.length - 2)
            sb.append(" }")

            return sb.toString()
        }
    }
}

Przykład użycia:

data class Actor(val id: Int, val name: String) {
    override fun toString(): String {
        return classToString(this)
    }
}