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

[JIRA] (LOGBACK-783) Support for compressing logfiles with bzip2
by QOS.CH (JIRA) 11 Oct '17

11 Oct '17

1 0

[JIRA] (LOGBACK-360) mssql.sql file has invalid schema
by QOS.CH (JIRA) 09 Oct '17

09 Oct '17

1 0

[JIRA] (LOGBACK-1095) FileName from StackTraceElement
by QOS.CH (JIRA) 09 Oct '17

09 Oct '17

1 0

[JIRA] (LOGBACK-493) Logging Exceptions using DBAppender fails (at least on Oracle), when message or stack frame is longer than 254 bytes
by QOS.CH (JIRA) 09 Oct '17

09 Oct '17

1 0

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

09 Oct '17

1 0

[JIRA] (LOGBACK-1027) Circular Referenced Suppressed Exception Throws StackOverflowError
by QOS.CH (JIRA) 06 Oct '17

06 Oct '17

1 0

[JIRA] (LOGBACK-1345) Support %F in access logs for time to first byte
by QOS.CH (JIRA) 06 Oct '17

06 Oct '17

Mat Mannion created LOGBACK-1345: ------------------------------------ Summary: Support %F in access logs for time to first byte Key: LOGBACK-1345 URL: https://jira.qos.ch/browse/LOGBACK-1345 Project: logback Issue Type: New Feature Components: logback-access Environment: Tomcat 8.5 Reporter: Mat Mannion Assignee: Logback dev list Currently [PatternLayout|https://logback.qos.ch/xref/ch/qos/logback/access/PatternLayout.html] supports {{%D}} for the total elapsed time (i.e. the time, in milliseconds, that the request was first received, to the time the last byte was sent to the client) but doesn't support {{%F}}, which is the time to the first byte being sent to the client. The [implementation in Tomcat|https://github.com/apache/tomcat/blob/91c3e7b61f3289dba83e35569c5d06…] appears, on the face of it, reasonably simple to replicate in {{AccessEvent}} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1344) RollingCalendar invalid period barrier closed computation
by QOS.CH (JIRA) 03 Oct '17

03 Oct '17

Boris Brinza created LOGBACK-1344: ------------------------------------- Summary: RollingCalendar invalid period barrier closed computation Key: LOGBACK-1344 URL: https://jira.qos.ch/browse/LOGBACK-1344 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Reporter: Boris Brinza Assignee: Logback dev list In RollingCalendar method periodBarriersCrossed, when periods are computed for TOP_OF_HOUR periodicity, unnecessary (and invalid) type cast is performed: {code:java} case TOP_OF_HOUR: return (long)((int)diff) / 3600000L;{code} in case diff > MAX_INT, return from method is wrong. example: {code:java} <fileNamePattern>logs/%d{yyyy/MM/dd,aux}/eps_%d{yyyyMMdd-HH}h.%i.log.zip</fileNamePattern> <cleanHistoryOnStart>true</cleanHistoryOnStart>{code} After i start application, method TimeBasedArchiverRemover.clean(Date now) is in some point called. Then, computation of period elapsed since last clean is called with parameters: {code:java} periodsElapsed = this.rc.periodBarriersCrossed(nowInMillis, nowInMillis + 2764800000L){code} where nowInMillis = 1507034734848 (date = Tue Oct 03 14:45:34 CEST 2017) In method, diff is computed (diff = 2761200000). This value > MAX_INT, so expression {code:java} (long)((int)diff) / 3600000L = -426{code} so no clean up is performed -- This message was sent by Atlassian JIRA (v7.3.1#73012)

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) 03 Oct '17

03 Oct '17

1 0

[JIRA] (LOGBACK-1299) ConcurrentModificationException when calling LoggerContext#addListener
by QOS.CH (JIRA) 03 Oct '17

03 Oct '17

1 0