Releases: hermannm/devlog-kotlin
Releases · hermannm/devlog-kotlin
v0.10.0
- Breaking: Bump minimum JVM target version from 8 -> 11
- Breaking: Prevent users from passing
LogBuilderas a log field value to thefieldfunction- Although this is technically a breaking change, this behavior was always a bug, which now causes a compilation failure to prevent users from accidentally passing the wrong log field value
- See this docstring for more on this
- Update Logback version
v0.9.2
- Improve performance of the
field()function overload that infers the serializer from its type parameter- The new implementation avoids the cost of an exception being constructed in the case where the type is not serializable
v0.9.1
- Update dependencies
- This includes updating
kotlinx.serializationto v1.10.0, which lets us drop the opt-in onExperimentalSerializationApi, sinceJsonUnquotedLiteralhas now been stabilized
- This includes updating
v0.9.0
- Breaking: Update major versions of Jackson (v3) and
logstash-logback-encoder(v9) - Add
Throwable.withLoggingContextextension function, allowing users to add log fields to exceptions without wrapping the original exception
v0.8.0
- Attach logging context to exceptions when they would escape the scope of
withLoggingContext- Previously, when an exception was thrown inside a logging context scope, one would lose that logging context if the exception was logged further up the stack (which is typical). But unexpected exceptions is when we need this context the most! So now,
withLoggingContextattaches its context fields to any encountered exception before re-throwing it up the stack, andLoggerincludes these fields when the exception is logged.
- Previously, when an exception was thrown inside a logging context scope, one would lose that logging context if the exception was logged further up the stack (which is typical). But unexpected exceptions is when we need this context the most! So now,
- Allow log fields to overwrite logging context fields for a single log
- Previously, duplicate keys could appear in the log output if the same key was used on a single-log field as on a logging context field.
- Use Kotlin Contracts in
withLoggingContext- This gives users more flexibility in what they can do in the given lambda.
- Breaking: Rename
ExceptionWithLogFieldstoExceptionWithLoggingContext, andHasLogFieldstoHasLoggingContext- This makes the naming of these classes more consistent with the
withLoggingContextfunction.
- This makes the naming of these classes more consistent with the
- Breaking:
ExceptionWithLoggingContextno longer implements theHasLoggingContextinterface- When it implemented this interface, it needlessly had to expose its
logFieldsproperty, which should be an implementation detail.
- When it implemented this interface, it needlessly had to expose its
- Breaking: Rename
getLoggingContexttogetCopyOfLoggingContext, change its return value to an opaqueLoggingContextwrapper class, and add newwithLoggingContextoverload that accepts this newLoggingContexttype- This new name is more explicit about what the function does, and also avoids competing with
getLoggerfor autocomplete. - The
LoggingContextwrapper class enables some performance optimizations, since we no longer need to turn the logging context into aList.
- This new name is more explicit about what the function does, and also avoids competing with
- Breaking: Use
Collectioninstead ofListin public APIs that accept or provide multiple log fieldsCollectionis a more flexible interface thanList.
- Breaking: Change return type of
rawJsonfunction fromkotlinx.serialization.json.JsonElementto customRawJsonwrapper type- This reduces the coupling of the library's API to
kotlinx.serialization, while keeping the same serialization behavior. In the future, we may want to support e.g. Jackson serialization on the JVM, so this gives us more flexibility.
- This reduces the coupling of the library's API to
- Change how JSON fields in
withLoggingContextare handled, to avoid internal implementation details leaking out- In the previous implementation, a key suffix was used to identify logging context fields with JSON values. But in certain log output configurations, this implementation detail could leak out. This implementation has now been reworked, both to avoid leaking implementation details and also to improve performance (by avoiding allocations).
- Minimize the amount of code in
inlinefunctions- Having a lot of code in
inlinefunctions increases code size (since that code is replicated wherever theinlinefunction is called), which can negatively affect perforamnce. The library now only includes the most necessary code ininlineblocks, delegating to normal functions where possible.
- Having a lot of code in
v0.7.0
v0.6.1
v0.6.0
- Change the
getLogger {}function using a lambda parameter to a zero-argumentgetLogger()function- This uses
MethodHandles.lookup().lookupClass(), as recommended by SLF4J
- This uses
- Mark the
buildLoglambda parameter on logger methods ascrossinline- This prevents users from accidentally doing a non-local return inside the lambda, which would drop the log
- Improve documentation
v0.5.0
- Restructure library for Kotlin Multiplatform
- JVM is still the only supported platform as of now, but this lays the groundwork for supporting more platforms in the future
- Add another
getLoggeroverload that takes aKClass - Allow using
fieldfunction with non-reified generics when passing a custom serializer - Rename
WithLogFieldsinterface to the more intuitiveHasLogFields - Add JVM-specific optimization annotations where appropriate, to reduce overhead
- Improve documentation
- Host documentation on https://devlog-kotlin.hermannm.dev
v0.4.0
- Take
causeexception as a normal argument onLoggermethods, instead of as a property onLogBuilder- This makes the normal case of logging a message along with an exception more concise
- Use SLF4J's MDC for logging context instead of a custom thread-local
- This allows our logging context to also apply to logs by libraries that use SLF4J
- A new
LoggingContextJsonFieldWriteris provided for Logback to enable JSON fields in MDC
- Rename
LogBuildermethods to be more concise and intuitiveaddFieldandaddRawJsonFieldare now justfieldandrawJsonField, like their top-level counterpartsaddPreconstructedFieldis nowaddField
- Add
LogBuilder.addFieldsmethod to make it easier to pass a list of pre-constructed fields - Add
ExecutorService.inheritLoggingContextextension function to make it easier to inherit logging context in tasks submitted to anExecutorService - Add more constructor overloads to
ExceptionWithLogFields, to allow passing log fields with less boilerplate - Fix edge case of unquoted strings being allowed by
rawJsonField - Improve documentation