December 2017 - logback-dev

[qos-ch/logback] e59b6d: ongoing work on jigsaw modularization
by Ceki Gulcu 02 Dec '17

02 Dec '17

Branch: refs/heads/master Home: https://github.com/qos-ch/logback Commit: e59b6d6b6f06263e5164335fe9c7cc2788e19a92 https://github.com/qos-ch/logback/commit/e59b6d6b6f06263e5164335fe9c7cc2788… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-12-02 (Sat, 02 Dec 2017) Changed paths: M logback-classic/pom.xml R logback-classic/src/main/java/ch/qos/logback/classic/provider/LogbackServiceProvider.java A logback-classic/src/main/java/ch/qos/logback/classic/spi/LogbackServiceProvider.java M logback-classic/src/main/java/ch/qos/logback/classic/spi/PackagingDataCalculator.java A logback-classic/src/main/java/module-info.Xjava R logback-classic/src/main/java/module-info.java R logback-classic/src/main/java/org/slf4j/impl/StaticLoggerBinder.java R logback-classic/src/main/java/org/slf4j/impl/StaticMDCBinder.java R logback-classic/src/main/java/org/slf4j/impl/StaticMarkerBinder.java A logback-classic/src/main/resources/META-INF/services/org.slf4j.spi.SLF4JServiceProvider M logback-classic/src/test/groovy/ch/qos/logback/classic/gaffer/GafferConfiguratorTest.groovy M logback-classic/src/test/input/gaffer/appenderRefWithNonAppenderAttachable.groovy M logback-classic/src/test/input/gaffer/asyncAppender.groovy M logback-classic/src/test/java/ch/qos/logback/classic/issue/logback1159/LogbackListenerTest.java M logback-classic/src/test/java/ch/qos/logback/classic/selector/ContextDetachingSCLTest.java M logback-classic/src/test/java/ch/qos/logback/classic/selector/ContextJNDISelectorTest.java R logback-classic/src/test/java/org/slf4j/LoggerFactoryFriend.java M logback-classic/src/test/java/org/slf4j/impl/InitializationOutputTest.java M logback-classic/src/test/java/org/slf4j/impl/RecursiveInitializationTest.java R logback-classic/src/test/java/org/slf4j/impl/StaticLoggerBinderFriend.java M logback-core/pom.xml A logback-core/src/main/java/module-info.Xjava R logback-core/src/main/java/module-info.java M pom.xml Log Message: ----------- ongoing work on jigsaw modularization

1 0

[qos-ch/logback] 0e2574: jigsaw modularization - ongoing work
by Ceki Gulcu 02 Dec '17

02 Dec '17

Branch: refs/heads/master Home: https://github.com/qos-ch/logback Commit: 0e25744d8da8d0300fe6f99b2873302b16684a0c https://github.com/qos-ch/logback/commit/0e25744d8da8d0300fe6f99b2873302b16… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-12-02 (Sat, 02 Dec 2017) Changed paths: A logback-classic/src/main/java/module-info.java A logback-core/src/main/java/module-info.java Log Message: ----------- jigsaw modularization - ongoing work

1 0

[JIRA] (LOGBACK-1356) Have MessageConverter include any extra arguments
by QOS.CH (JIRA) 01 Dec '17

01 Dec '17

1 0

[JIRA] (LOGBACK-1356) Have MessageConverter include any extra arguments
by QOS.CH (JIRA) 01 Dec '17

01 Dec '17

Eric Pabst created LOGBACK-1356: ----------------------------------- Summary: Have MessageConverter include any extra arguments Key: LOGBACK-1356 URL: https://jira.qos.ch/browse/LOGBACK-1356 Project: logback Issue Type: Improvement Components: logback-classic Affects Versions: 1.2.3 Environment: All Reporter: Eric Pabst Assignee: Logback dev list The purpose of logging to slf4j is to allow code to log information without worrying about which implementation and format will be used for actual logging. In deployed environments, we prefer JSON logging using logstash to be consumed by Splunk, which handles JSON very nicely. However, for local development and testing, we prefer text output via logback-classic. We often want to log extra fields to show up in the JSON output such as {{\{ "timestamp": "2017...", "message": "Event X happened", "userName": "bob", "url": "http://..."}}} To accomplish this, we use logstash's StructuredArgument to provide extra arguments to the Logger: {{import static net.logstash.logback.argument.StructuredArguments.keyValue;}} {{...}} {{ LOGGER.info("Event X happened", keyValue("userName", "bob"), keyValue("url", "http://..."));}} We don't want to include \{}'s in the message or else it would log the username and url both in the message and as separate JSON properties. However, when binding to logback-classic, it is logged without these extra arguments: {{INFO 2017... Event X happened}} It would help immensely to include these extra arguments automatically if present: INFO 2017... Event X happened username=bob url=http://... -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1355) Cannot rollover when currentlyActiveFile renamed and size reduced by other process
by QOS.CH (JIRA) 01 Dec '17

01 Dec '17

hebelala created LOGBACK-1355: --------------------------------- Summary: Cannot rollover when currentlyActiveFile renamed and size reduced by other process Key: LOGBACK-1355 URL: https://jira.qos.ch/browse/LOGBACK-1355 Project: logback Issue Type: Bug Components: logback-core Environment: SizeBasedTriggeringPolicy's is`TriggeringEvent` method should use `ResilientFileOutputStream.getChannel().size()` to replace `activeFile.length()`, because the activeFile maybe already is not matched with the outputStream. Reporter: hebelala Assignee: Logback dev list Priority: Critical -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1354) Errors cause AsyncAppender's worker thread to terminate causing halting
by QOS.CH (JIRA) 01 Dec '17

01 Dec '17

Greg created LOGBACK-1354: ----------------------------- Summary: Errors cause AsyncAppender's worker thread to terminate causing halting Key: LOGBACK-1354 URL: https://jira.qos.ch/browse/LOGBACK-1354 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Environment: (Not environment specific.) Reporter: Greg Assignee: Logback dev list The AsyncAppender worker thread, defined in AsyncAppenderBase, consumes log entries from a bounded blocking queue. Should this worker thread terminate prematurely for any reason and the AsyncAppender be configured as blocking (neverBlock=false) the queue fills and any calls to log block indefinitely. The worker thread is currently indirectly tolerant of exceptions thrown by an appender, due to the exception handling in AppenderBase.doAppend, but this exception handling does not cover other Throwable types. Ideally, the AsyncAppender worker thread should do everything possible to stay alive while the appender is started. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0