November 2017 - logback-dev

[JIRA] (LOGBACK-1322) File handles to tmp file kept open after rotation
by QOS.CH (JIRA) 10 Nov '17

10 Nov '17

1 0

[JIRA] (LOGBACK-1322) File handles to tmp file kept open after rotation
by QOS.CH (JIRA) 10 Nov '17

10 Nov '17

1 0

[JIRA] (LOGBACK-1352) Provide an public API do modify ConsoleTarget.SystemOut & Err
by QOS.CH (JIRA) 09 Nov '17

09 Nov '17

Gael Lalire created LOGBACK-1352: ------------------------------------ Summary: Provide an public API do modify ConsoleTarget.SystemOut & Err Key: LOGBACK-1352 URL: https://jira.qos.ch/browse/LOGBACK-1352 Project: logback Issue Type: Improvement Reporter: Gael Lalire Assignee: Logback dev list Priority: Minor I give via reflection access to System.out & System.err to ConsoleTarget. {code:java} Field streamField = ConsoleTarget.class.getDeclaredField("stream"); streamField.setAccessible(true); streamField.set(ConsoleTarget.SystemOut, System.out); streamField.set(ConsoleTarget.SystemErr, System.err); streamField.setAccessible(false);{code} Then I change the value of System.out & System.err, so they will create a call to info or error for each line received. It would be nicer if I did not have to use reflection to do this. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1351) MDC issue
by QOS.CH (JIRA) 09 Nov '17

09 Nov '17

Gael Lalire created LOGBACK-1351: ------------------------------------ Summary: MDC issue Key: LOGBACK-1351 URL: https://jira.qos.ch/browse/LOGBACK-1351 Project: logback Issue Type: Bug Components: logback-classic Reporter: Gael Lalire Assignee: Logback dev list After -LOGBACK-620-, the MDC map is no longer in InheritableThreadLocal. So when you MDC.put on a thread if you create a new thread from it, the new thread will not receive the value. I think the -LOGBACK-620- was about not copying the map on each thread creation but only when it the map is modified, but the lost of inherited value was unexpected. If so replacing {code:java} final ThreadLocal<Map<String, String>> copyOnThreadLocal = new ThreadLocal<Map<String, String>>();{code} by {code:java} final ThreadLocal<Map<String, String>> copyOnThreadLocal = new InheritableThreadLocal<Map<String, String>>();{code} will do the fix -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1341) SizeAndTimeBasedRollingPolicy does not zip all the files on day change
by QOS.CH (JIRA) 09 Nov '17

09 Nov '17

1 0

[JIRA] (LOGBACK-1289) SizeAndTimeBasedRollingPolicy does not roll to the new date
by QOS.CH (JIRA) 09 Nov '17

09 Nov '17

1 0

[JIRA] (LOGBACK-1350) After rolling logback writes to the old and the new file.
by QOS.CH (JIRA) 09 Nov '17

09 Nov '17

1 0

[JIRA] (LOGBACK-1214) Every night after the use of the log scroll compression, there is no release of the handle
by QOS.CH (JIRA) 09 Nov '17

09 Nov '17

1 0

[JIRA] (LOGBACK-1322) File handles to tmp file kept open after rotation
by QOS.CH (JIRA) 09 Nov '17

09 Nov '17

1 0

[JIRA] (LOGBACK-1350) After rolling logback writes to the old and the new file.
by QOS.CH (JIRA) 09 Nov '17

09 Nov '17

Merlijn van der Mee created LOGBACK-1350: -------------------------------------------- Summary: After rolling logback writes to the old and the new file. Key: LOGBACK-1350 URL: https://jira.qos.ch/browse/LOGBACK-1350 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Environment: Linux 2.6.32-696.el6.x86_64 Grails 3 application on tomcat 8.0.32 Reporter: Merlijn van der Mee Assignee: Logback dev list After rolling (without zipping) logback continues to log some threads to the old logfile and some to the new logfile. With statusListener(OnConsoleStatusListener) in logback.groovy I can see that the roll-over occurs twice. \{code} 17:00:02,500 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Thu Nov 09 16:57:30 CET 2017 17:00:02,501 |-INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [logs/jdbc-iom.log] to [logs/jdbc-iom.log.2017-11-09-16] 17:00:02,507 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - first clean up after appender initialization 17:00:04,099 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Elapsed period: Thu Nov 09 16:56:22 CET 2017 17:00:04,100 |-INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [logs/jdbc-iom.log] to [logs/jdbc-iom.log.2017-11-09-16] 17:00:04,104 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - first clean up after appender initialization \{code} When rolling and zipping (what we actually use) the second rolling gives an error since the zip file already exists and leaves the .tmp file. After this, it logs some theads to the new file and other threads to the xxx.tmp file. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0