[ https://jira.qos.ch/browse/SLF4J-424?page=com.atlassian.jira.plugin.system.i... ] Will Sargent commented on SLF4J-424: ------------------------------------ I've implemented much of this with wrappers in terse-logback: [https://github.com/tersesystems/terse-logback/blob/master/example/src/main/j...] There's also the godaddy-logger API: [https://github.com/godaddy/godaddy-logger] and slf4j-fluent: https://github.com/ffissore/slf4j-fluent
extend "Logger" with fluent API to simplify logging calls with additional information (via MDC) -----------------------------------------------------------------------------------------------
Key: SLF4J-424 URL: https://jira.qos.ch/browse/SLF4J-424 Project: SLF4J Issue Type: Improvement Components: Core API Reporter: Christian Lorenz Assignee: SLF4J developers list
Hi, In our project we use SLF4J with Logback and logstash-logback-encoder. To use the advantages of ELK (Logstash) we set fields via MDC within the processing flow, but sometimes we also want to create custom fields (by using MDC) just for a single log message. Unfortunately the SLF4J Logger API does not provide a easy way to do that. To improve the API I've started implementing a fluent API to log messages. [https://github.com/jackhammer2k/slf4j/commit/f3e768260b6f109d1f207e43c48e8ca...] The approach should not affect the performance, but increases readability and extensibility. The message builder can be extended for other stuff as well, but this is enough for us at least. To avoid breaking all existing implementations I changed the module name to "slf4j-api-jdk8" and implemented so far unused methods like "info()" as "default" interface methods. The idea is to provide that extra package as an alternative for all Java 8 applications that want to replace their "slf4j-api" dependency. Like other libraries provide backwards-compatible versions for old JDKs. Its fully compatible with the whole SLF4J ecosystem. The module will be developed in the branch "slf4j-api-jdk8" forever. Thus during a release all modules will be released, master merged and only this module released from the branch as well. I would really like to see this extension within SLF4J instead of continuing with an own "extension library" used only internally. So far I've implemented just the info() method to show the idea, but if its accepted to be part of official SLF4J I will continue with the implementation. Cheers, Christian
-- This message was sent by Atlassian JIRA (v7.3.1#73012)