It would be great if extraction of contextItems could be configurable, ability to provide a lambda etc.

This way I could implement my own function to extract fields from for example ReactorContext (kotlinx.coroutines.reactor.ReactorContext) to avoid adding klogging context and mapping fields there on all log invocations.

I suppose I could implement my own Klogger for this, but base support seems nice to have.

Whenever I use any type of log in my application, I get this exception below. For context, it is a Compose for Desktop application. I have tried defining the logger both through an interface and directly and they all cause this same crash once any log tries to be run.

Exception in thread "DefaultDispatcher-worker-1" java.lang.IncompatibleClassChangeError: Found interface kotlin.time.TimeMark, but class was expected
	at io.klogging.sending.BatchingKt.receiveBatch(Batching.kt:48)
	at io.klogging.internal.Sink$sinkChannel$2$1.invokeSuspend(Sink.kt:58)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:749)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)
	Suppressed: kotlinx.coroutines.DiagnosticCoroutineContextException: [CoroutineName(sink-console), StandaloneCoroutine{Cancelling}@5415e1fd, Dispatchers.Default]

The issue is with jacoco configuration, with existing configuration jacoco was not able to generate report for kotlin multiplatform project.

Reference: https://stackoverflow.com/questions/59802396/kotlin-multiplatform-coverage Coverage Report: https://codecov.io/github/ashishkujoy/klogging/commit/7702016938f7c55c0f117db48385d8e30bbf9caf

There is a single Kotlin object with state of Klogging in a running application. It contains properties with holders for values that can be safely mutated.

Properties to include:

• MInimum log level for Klogging
• Current configuration in a KloggingConfiguration (as class) isntance
• Coroutine dispatcher(s) used by Klogging

These tests illustrate shortcomings to Timestamp:

    describe("Timestamps") {
        val somewhen = Timestamp(2L, 3L)

        it("represents as UTC time") {
            somewhen.isoString shouldBe "1970-01-01T00:00:02.000000003Z"
        }
        it("represents as local time") {
            // TODO: Control for locale and time zone
            somewhen.localString shouldBe "1970-01-01 08:00:02.000000003"
        }
    }

1. Local time does not show the time zone or offset from GMT
2. No format configuration available
   • Some users may want to control timestamp format, eg, for consumption by a system with format limitations
   • Item # 1 is less a concern if users can configure format
3. Valid ISO 8601 formats include, meaning, these are the "official" formats (usually with an extension for millis, micros, or nanos), so there is not a single universal choice:
   • 2021-08-06T03:08:10+00:00
   • 2021-08-06T03:08:10Z
   • 20210806T030810Z
4. For timestamps, local formatting should be strongly discouraged

(Please ignore the TODO marker above. This is a note for myself to avoid a flaky time zone-based test.)

• Fix a typo with numbering of sequential items (1,2,3 vs 1,2,4)
• Move logo to right, flow text around it
• Scale logo (% vs pt) so it looks right on any device
• IntelliJ reformatted the text layout
• A grammar tweak

Note: When Klogging has an independent site (eg, like Batect), the logo can be wrapped with an anchor tag for each one-click access.

Would be nice if you add support for lazy API as well e.g. logger.debug { "Some $expensive message!" }

fun debug(msg: () -> Any?) {
    if(isDebugEnabled)  debug(msg().takeIf { it != Unit }?.toString().orEmpty())
}

Bumps codecov/codecov-action from 2.1.0 to 3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

When a configuration specifies logger names that contain Regex special characters, they don’t match properly.

For example the configuration:

    exactLogger("[R]:[KTOR]:[ExclusionRequestRateLimiter]")

will not match because code in LoggingConfig constructs a Regex instance with:

    nameMatch = Regex("^$exactName\$")

Several commits together. Key points:

• I started from writing tests, and wound up with the below to get the tests passing (see "does not log" block of tests)
• IMPORTANT -- please review how NONE is handled, especially for: public fun isLevelEnabled(level: Level): Boolean = NONE != level && minLevel() <= level
• Short-circuit checks in methods like log to skip processing if the log level is disabled
• Formatting courtesy of IntelliJ
• Remove useless code in batect.yml (which I added myself previously: I had not noticed the GRADLE_OPTS env var)

This is more a matter of personal taste. More open source projects use a package naming scheme corresponding roughly to a reversed FQDN domain name.

So perhaps, org.klogger rather than just klogger?

I also note that the domain name, "klogger.org", is not taken.

The function Dispatcher.sinksFor() calculates the current set of sinks every time a log event is dispatched. This might be very inefficient with large numbers of log events.

Perhaps introduce a simple cache (map) of sinks, keyed by logger name. Considerations:

• What if there is a very large number of logger names? Could the map grow very large? (YAGNI?)
• How often might the configuration change? Level configurations can be changed by calling the config DSL in a running application. Perhaps introduce simple cache invalidation? (YAGNI?)

Given this main function

fun main() {
    loggingConfiguration {
        DEFAULT_CONSOLE()
    }
    val logger = noCoLogger("Log")
    logger.info("Hello World")

    /** Uncomment to see the log: INFO [main] Log : Hello World **/
    // Thread.sleep(100)
}

I expect to see:

12:46:55.381571  INFO [                main] :        Configuration : Setting configuration using the DSL with append=false
2022-03-01 12:47:19.539911 INFO [main] Log : Hello World

but I see

12:46:55.381571  INFO [                main] :        Configuration : Setting configuration using the DSL with append=false

If I uncomment the Thread.sleep(100), I see both lines.

What I am missing?

Optionally add file and line information to log events. See discussion in this thread: https://kotlinlang.slack.com/archives/C1NNEMDBK/p1634476948004100

Currently Klogging may be configured with klogging.json, but it's a better practice in the JVM world to use HOCON for user-controlled (i.e. not generated) configuration. tl;dr:

JSON:

- easy to generate programmatically
- well-defined and standard
- bad for human maintenance, with no way to write comments, and no mechanisms to avoid duplication of similar config sections

HOCON/.conf:

- nice for humans to read, type, and maintain, with more lenient syntax
- built-in tools to avoid cut-and-paste
- ways to refer to the system environment, such as system properties and environment variables

Also, Ktor uses resources/application.conf (i.e. HOCON file in resources dir) for server configuration, so sourcing Klogging config from resources/klogging.conf would add more consistency to Ktor app configuration.

For RenderGelf, the FATAL Klogging level, maps to "2" (critical) level for syslog/greylog. Why "critical" as opposed to "alert"? Perhaps documentation explaining the mapping.