March 2017 - logback-dev - mailman3.qos.ch

[qos-ch/logback] b0ede8: fix LOGBACK-1287
by Ceki Gulcu 22 Mar '17

22 Mar '17

Branch: refs/heads/master Home: https://github.com/qos-ch/logback Commit: b0ede870f6acec8b1ec27ee90a8e664a62307d0d https://github.com/qos-ch/logback/commit/b0ede870f6acec8b1ec27ee90a8e664a62… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-03-22 (Wed, 22 Mar 2017) Changed paths: M logback-core/src/main/java/ch/qos/logback/core/encoder/LayoutWrappingEncoder.java Log Message: ----------- fix LOGBACK-1287

1 0

[JIRA] (LOGBACK-1287) Breaking change? Custom appender can not be assigned to OutputStreamAppender
by QOS.CH (JIRA) 22 Mar '17

22 Mar '17

Jack created LOGBACK-1287: ----------------------------- Summary: Breaking change? Custom appender can not be assigned to OutputStreamAppender Key: LOGBACK-1287 URL: https://jira.qos.ch/browse/LOGBACK-1287 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.2, 1.2.1 Reporter: Jack Assignee: Logback dev list Priority: Blocker With the release of logback 1.2.1 our custom appender does not work anymore and Joran fails with the error below: {noformat} INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property ERROR in ch.qos.logback.core.joran.util.PropertySetter@434f3900 - A "com.example.logging.logback.extensions.DebugFileDumper" object is not assignable to a "ch.qos.logback.core.OutputStreamAppender" variable. The class "ch.qos.logback.core.OutputStreamAppender" was loaded by [startJarLoader@2d95ebec] whereas object of type "com.example.logging.logback.extensions.DebugFileDumper" was loaded by [startJarLoader@2d95ebec]. {noformat} I think the issue has been introduced by commit: [https://github.com/qos-ch/logback/commit/d3d704c12e7b8e6503187744ac2200c244…] which makes {{LayoutWrappingEncoder}} assume that it is always owned by an OutputstreamAppender: [https://github.com/qos-ch/logback/commit/d3d704c12e7b8e6503187744ac2200c244…] However our custom Appender extends AppenderBase and uses composition to use two FileAppenders internally. The encoder of one of those FileAppenders can be configured in logback.xml while the other has a fixed encoding. Basically the Java code delegates setEncoder() to a FileAppender. Code roughly looks like: {code:java} public class DebugFileDumper extends AppenderBase<ILoggingEvent> { // writes a debug-timestamp.log from a cyclic buffer private FileAppender<ILoggingEvent> debugBufferFileDumper; // writes a debug-timestamp.meta containing corresponding meta infos stored in MDC in an easy to parse key=value format for further processing by external tools. private FileAppender<ILoggingEvent> mdcFileDumper; // ... additional properties public DebugFileDumper() { mdcFileDumper.setEncoder(new MdcOnlyEncoder()); } public void setEncoder(Encoder<ILoggingEvent> encoder) { debugBufferFileDumper.setEncoder(encoder); } public Encoder<ILoggingEvent> getEncoder() { return debugBufferFileDumper.getEncoder(); } // .. additional methods } {code} With configuration like: {code:xml} <appender name="debugDumper" class="com.example.logging.logback.extensions.DebugFileDumper"> <discriminator class="ch.qos.logback.classic.sift.MDCBasedDiscriminator"> <key>SESSION_ID</key> <defaultValue>server</defaultValue> </discriminator> <evaluator class="ch.qos.logback.classic.boolex.OnErrorEvaluator" /> <cyclicBufferTracker class="ch.qos.logback.core.spi.CyclicBufferTracker"> <bufferSize>128</bufferSize> <maxComponents>128</maxComponents> <timeout>1800000</timeout> </cyclicBufferTracker> <folder>${logback.logs}/dumps</folder> <encoder> <pattern>[SOME PATTERN FOR DEBUG LOG FILE]</pattern> </encoder> </appender> {code} I think our implementation strategy is valid and the assumption made in the mentioned commit, that an encoder configuration block always belongs to an OutputStreamAppender, is a bit too strict. Basically composition/delegation pattern hasn't been taken into account. Currently we would need to rewrite our appender in order to make it work with Logback 1.2.1+, so I thought I should let you know about that implicit breaking change. Maybe it was not intended on your side and you can relax the assumption to fix our issue. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1277) Capping log files does not work with large log file base
by QOS.CH (JIRA) 22 Mar '17

22 Mar '17

1 0

[qos-ch/logback] 4d2a6a: Remove disturbing println
by Ceki Gulcu 21 Mar '17

21 Mar '17

Branch: refs/heads/master Home: https://github.com/qos-ch/logback Commit: 4d2a6a6579ce5b9a1e79be8557989574bd196e5f https://github.com/qos-ch/logback/commit/4d2a6a6579ce5b9a1e79be8557989574bd… Author: Thibault Meyer <meyer.thibault(a)gmail.com> Date: 2017-03-21 (Tue, 21 Mar 2017) Changed paths: M logback-core/src/main/java/ch/qos/logback/core/AsyncAppenderBase.java Log Message: ----------- Remove disturbing println Signed-off-by: Thibault Meyer <meyer.thibault(a)gmail.com> Commit: 6165653f62fe6ccd82b4a849e6ad636f357eb835 https://github.com/qos-ch/logback/commit/6165653f62fe6ccd82b4a849e6ad636f35… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-03-21 (Tue, 21 Mar 2017) Changed paths: M logback-core/src/main/java/ch/qos/logback/core/AsyncAppenderBase.java Log Message: ----------- Merge pull request #369 from 0xbaadf00d/feature/remove-println Remove disturbing println Compare: https://github.com/qos-ch/logback/compare/ed3ec5be6830...6165653f62fe

1 0

[JIRA] (LOGBACK-1286) Add discardWhenFull config option to AsyncAppender
by QOS.CH (JIRA) 21 Mar '17

21 Mar '17

1 0

[JIRA] (LOGBACK-1286) Add discardWhenFull config option to AsyncAppender
by QOS.CH (JIRA) 21 Mar '17

21 Mar '17

1 0

[JIRA] (LOGBACK-1286) Add discardWhenFull config option to AsyncAppender
by QOS.CH (JIRA) 21 Mar '17

21 Mar '17

1 0

[JIRA] (LOGBACK-1286) Add discardWhenFull config option to AsyncAppender
by QOS.CH (JIRA) 20 Mar '17

20 Mar '17

Scott Wilson created LOGBACK-1286: ------------------------------------- Summary: Add discardWhenFull config option to AsyncAppender Key: LOGBACK-1286 URL: https://jira.qos.ch/browse/LOGBACK-1286 Project: logback Issue Type: Improvement Components: logback-classic Affects Versions: 1.1.11 Reporter: Scott Wilson Assignee: Logback dev list The current AsyncAppender implementation blocks once the queue is full. In some situations the user would rather lose log messages than block on the log call. It would be very helpful to make this configurable. My current workaround is to create a class that extends AsyncAppenderBase and overrides the append() method and calls blockingQueue.offer() instead of put(). Suggested solution: # Add a configurable attribute such as discardWhenFull that defaults to false # In AsyncAppenderBase.append() use blockingQueue.offer() if discardWhenFull is true -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/logback] ed3ec5: no point in writing zero length arrays
by Ceki Gulcu 20 Mar '17

20 Mar '17

Branch: refs/heads/master Home: https://github.com/qos-ch/logback Commit: ed3ec5be6830bd786705875cc8f6ab9c4937d6e9 https://github.com/qos-ch/logback/commit/ed3ec5be6830bd786705875cc8f6ab9c49… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-03-20 (Mon, 20 Mar 2017) Changed paths: M logback-core/src/main/java/ch/qos/logback/core/OutputStreamAppender.java Log Message: ----------- no point in writing zero length arrays

1 0

[JIRA] (LOGBACK-1282) ConsoleAppender shows logback error in Java console on startup
by QOS.CH (JIRA) 20 Mar '17

20 Mar '17

1 0