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

removing context selectors will break our libraries and applications
by Garret Wilson 28 Apr '19

28 Apr '19

Hi, I've been pretty deep inside the Logback code. In fact I wrote a comprehensive explanation on the bootstrap procedure here: https://stackoverflow.com/a/38317149/421049 We've created a library called Csar that allows one to configure various configuration "contexts" within the same JVM, for a program that has different locales at the same time, or different logging configurations for different users, etc. I explain this all at https://dzone.com/articles/creating-local-globals-with-csar . Our Clogr library used Csar to allow different logging configurations (or even different logging libraries!) to be set up for different parts of the application. (Imagine a server with different user sessions, each session being logged to a different file.) We got this working great for Logback. In fact we integrated it into our software development course; read about it here: https://clogr.io/learn (See the section on Clogr and compartmentalized configurations with Logback at the bottom.) The problem is that the initial bootstrap sequence of Logback was brittle, relying on a static class that could appear across modules. The appearance of the Java 9+ module system prohibits this altogether. But I had already created a ticket https://jira.qos.ch/browse/LOGBACK-1196 for how to fix this, long before the Java system was released, using the standard service provider mechanism. But now I see at https://logback.qos.ch/news.html that Logback will remove contexts altogether. This will break our ability to configure loggers separately in our application, and to use Clogr to manage them. Why remove this? There was nothing wrong with the simple context selection. The problem was how it was configured, using a static classes that had to be placed in a module outside its package. Just implement https://jira.qos.ch/browse/LOGBACK-1196, please. Don't break our application. I even provide much of the code to do this at LOGBACK-1196. What can we do to keep this from being removed and breaking our library? Why do we need to remove it in the first place? Why not fix it? (Ironically I was just told that Log4j 2 supports contexts, so maybe our application will have to switch back to Log4j. But I would prefer to have Clogr support both Logback and Log4j 2. There is no reason to remove this capability from Logback.) As I mentioned two years ago in LOGBACK-1196, I'm willing to contribute to fixing this. Let me know how to go forward. Thanks, Garret Wilson President GlobalMentor, Inc.

2 3

[JIRA] (LOGBACK-1434) Logback fails to log when collecting estimated Memory Size
by QOS.CH (JIRA) 31 Oct '18

31 Oct '18

1 0

[JIRA] (LOGBACK-1434) Logback fails to log when collecting estimated Memory Size
by QOS.CH (JIRA) 29 Oct '18

29 Oct '18

1 0

[JIRA] (LOGBACK-1435) Logback is case sensitive for configuration file extension
by QOS.CH (JIRA) 29 Oct '18

29 Oct '18

Michael Banks created LOGBACK-1435: -------------------------------------- Summary: Logback is case sensitive for configuration file extension Key: LOGBACK-1435 URL: https://jira.qos.ch/browse/LOGBACK-1435 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Environment: Operating System: Windows Platform: PC Reporter: Michael Banks Assignee: Logback dev list Currently, if the configuration filename does not end in 'xml' or 'groovy', the logging system will fail to initialize. However, when attempting to run Tomcat as a service on Windows the filename is passed to the ContextInitializer as a Windows _short_ file name where the extension is upper case (e.g. file:/C:/openedge/wrk/OEPASS~1/conf/LOGGIN~3.XML). The check for 'xml' or 'groovy' is not case insensitive, so the (valid) file name is rejected. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1434) Logback fails to log when collecting estimated Memory Size
by QOS.CH (JIRA) 29 Oct '18

29 Oct '18

Matthias Schmidt created LOGBACK-1434: ----------------------------------------- Summary: Logback fails to log when collecting estimated Memory Size Key: LOGBACK-1434 URL: https://jira.qos.ch/browse/LOGBACK-1434 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.0.7 Reporter: Matthias Schmidt Assignee: Logback dev list Priority: Minor Hey together, we are running java melody 1.73.1 on a tomcat server. it seems like the logging framework of our java melody instance crashes at some time, so the application throws an exception everytime it tries to log something. according to the stacktrace, java melody is collecting some information from the java information list. during this process, there is some exception happening. because of the crashed logback framework, we cannot see what kind of exception this is. see stacktrace: java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy at ch.qos.logback.classic.spi.LoggingEvent.(LoggingEvent.java:119) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:420) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:384) at ch.qos.logback.classic.Logger.warn(Logger.java:693) at net.bull.javamelody.LogbackLogger.warn(LogbackLogger.java:58) at net.bull.javamelody.LOG.warn(LOG.java:102) at net.bull.javamelody.Collector.collectWithoutErrors(Collector.java:308) at net.bull.javamelody.Collector.collectLocalContextWithoutErrors(Collector.java:294) at net.bull.javamelody.FilterContext$CollectTimerTask.run(FilterContext.java:56) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) obviously, the logback library is accessible, because a part of the logback code is executed successfully. the process is crashing when the logback library tries to access the ThrowableProxy. according to some research, this may happen when the logback process is shut down at some time, but the application is still running or restarted at some point. is there any idea or experience how or when this issue could occur? thanks -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1433) Add support for ANSI style modifiers like "dim/faint"
by QOS.CH (JIRA) 28 Oct '18

28 Oct '18

Marcel Overdijk created LOGBACK-1433: ---------------------------------------- Summary: Add support for ANSI style modifiers like "dim/faint" Key: LOGBACK-1433 URL: https://jira.qos.ch/browse/LOGBACK-1433 Project: logback Issue Type: Improvement Environment: Besides logback currently supports coloring like %cyan, %highlight it would be nice if other ANSI styles would be supported like "dim"/"faint". E.g. using %dim(..) Is there maybe a workaround available to use these ANSI styles already? I currently have this pattern: {noformat} <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%-15.15thread] %highlight(%-5level) %cyan(%-40.40logger{39}) - %message%n</pattern>{noformat} But I would like to dim the date being logged. Reporter: Marcel Overdijk Assignee: Logback dev list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-738) optionally suppress empty value error from insertFromJNDI
by QOS.CH (JIRA) 26 Oct '18

26 Oct '18

1 0

[JIRA] (LOGBACK-1432) Cleaning old log files created by Sifting appender child
by QOS.CH (JIRA) 25 Oct '18

25 Oct '18

Masha Buka created LOGBACK-1432: ----------------------------------- Summary: Cleaning old log files created by Sifting appender child Key: LOGBACK-1432 URL: https://jira.qos.ch/browse/LOGBACK-1432 Project: logback Issue Type: Bug Environment: I have SiftingAppender which creates logs per each job run. I need to automatically clean log files which are 2 weeks old. I tried to use RollingAppender, but it does not work since each log file name has unique job run id. This is what I have tired so far: {code:java} <configuration>  <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> <appender name="JOB_LOG" class="ch.qos.logback.classic.sift.SiftingAppender">   <discriminator> <key>jobRunId</key> <defaultValue>null</defaultValue> </discriminator>  <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator class="ch.qos.logback.classic.boolex.JaninoEventEvaluator"> <expression> mdc.get("jobRunId") == null </expression> </evaluator> <OnMismatch>NEUTRAL</OnMismatch> <OnMatch>DENY</OnMatch> </filter> <sift> <appender name="FILE-${jobRunId}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/jobs/${jobRunId}.log</file> <encoder> <pattern>%d{HH:mm:ss.SSS} [%level] [%logger{60}] - %msg%n</pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <fileNamePattern>logs/jobs/%d{yyyy-MM-dd_HH:mm:ss}.${jobRunId}.log</fileNamePattern>  <maxHistory>5</maxHistory> <cleanHistoryOnStart>true</cleanHistoryOnStart> </rollingPolicy> </appender> </sift> </appender> <root level="TRACE"> <appender-ref ref="JOB_LOG"/> </root> </configuration> {code} Console log suggests that files have been archived. But clean on start does not delete them I would assume since each appender name is dynamic in my case: {code} 15:18:15,194 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender] 15:18:15,197 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [FILE-aFuq3Q8H96] 15:18:15,204 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property 15:18:15,228 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - No compression will be used 15:18:15,230 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use the pattern logs/jobs/%d{yyyy-MM-dd_HH:mm:ss}.aFuq3Q8H96.log for the active file 15:18:15,234 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd_HH:mm:ss' from file name pattern 'logs/jobs/%d{yyyy-MM-dd_HH:mm:ss}.aFuq3Q8H96.log'. 15:18:15,234 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over every second. 15:18:15,234 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Thu Oct 25 15:18:15 PDT 2018 15:18:15,235 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Cleaning on start up 15:18:15,235 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - first clean up after appender initialization 15:18:15,235 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - periodsElapsed = 336 15:18:15,257 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE-aFuq3Q8H96] - Active log file name: /logs/jobs/aFuq3Q8H96.log 15:18:15,258 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE-aFuq3Q8H96] - File property is set to [/logs/jobs/aFuq3Q8H96.log] 15:18:15.193 INFO c.l.t.logging.testing.LogbackTest - Hello, I am MDC 15:18:17.261 INFO c.l.t.logging.testing.LogbackTest - Hello, I am not MDC 15:18:17,262 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender] 15:18:17,262 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [FILE-CjA2HVpgTq] 15:18:17,262 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property 15:18:17,264 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - No compression will be used 15:18:17,264 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use the pattern /logs/jobs/%d{yyyy-MM-dd_HH:mm:ss}.CjA2HVpgTq.log for the active file 15:18:17,265 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd_HH:mm:ss' from file name pattern '/logs/jobs/%d{yyyy-MM-dd_HH:mm:ss}.CjA2HVpgTq.log'. 15:18:17,265 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over every second. 15:18:17,265 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Thu Oct 25 15:18:17 PDT 2018 15:18:17,265 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Cleaning on start up 15:18:17,265 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - first clean up after appender initialization 15:18:17,265 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - periodsElapsed = 336 15:18:17,277 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE-CjA2HVpgTq] - Active log file name: /logs/jobs/CjA2HVpgTq.log 15:18:17,277 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE-CjA2HVpgTq] - File property is set to [/logs/jobs/CjA2HVpgTq.log] 15:18:17.261 INFO c.l.t.logging.testing.LogbackTest - Hello, I am MDC 15:18:19.277 INFO c.l.t.logging.testing.LogbackTest - Hello, I am not MDC{code} Reporter: Masha Buka Assignee: Logback dev list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1431) SizeBasedTriggeringPolicy and FixedWindowRollingPolicy : file grows enormously in some cases
by QOS.CH (JIRA) 23 Oct '18

23 Oct '18

Alisa Martirosyan created LOGBACK-1431: ------------------------------------------ Summary: SizeBasedTriggeringPolicy and FixedWindowRollingPolicy : file grows enormously in some cases Key: LOGBACK-1431 URL: https://jira.qos.ch/browse/LOGBACK-1431 Project: logback Issue Type: Bug Components: logback-classic, logback-core Affects Versions: 1.2.3 Environment: Logback 1.2.3, RHEL 6 Reporter: Alisa Martirosyan Assignee: Logback dev list Hi there, Using logback 1.2.3. We have SizeBased and FixedWindow policy described as follows: <appender name="METRICS" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>\{filename}</file> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>\{filename}.%i.log</fileNamePattern> <minIndex>1</minIndex> <maxIndex>9</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>20MB</maxFileSize> </triggeringPolicy> <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder"> <layout class="com.avaya.ept.common.logging.layout.CLFLayout"> <pattern>|%thread|%level|%logger\{15}|%msg%n</pattern> </layout> </encoder> </appender> Recently we've faced the issue when log file \{filename}-1.log grows to the enormous size of 40gb without any particular reason. After removing this log and restarting the application log continues to rotate normally, on ~20mb size mark. We could not analyze the logs as they causes the system to freeze (due to lack of free disk space) and had to be removed ASAP. Is there any particular reason why this could be happen? Using RHEL 6. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LBAUDIT-6) Logback documentation not tied to releases
by QOS.CH (JIRA) 18 Oct '18

18 Oct '18

Joachim Durchholz created LBAUDIT-6: --------------------------------------- Summary: Logback documentation not tied to releases Key: LBAUDIT-6 URL: https://jira.qos.ch/browse/LBAUDIT-6 Project: logback-audit Issue Type: Bug Reporter: Joachim Durchholz Assignee: Logback dev list Priority: Blocker [https://logback.qos.ch/manual/] does not state what version of Logback it refers to. There is no link to older versions of Logback. My personal use case: The documentation told me that {{<configuration {color:#d04437}scanPeriod{color}=...>}} is optional, but this is a new feature in 1.3.0-alpha, and not present in 1.2.3 which we're using because, well, alpha. Effect was that {{scan="true"}} would not have any effect because that's the way how 1.2.3 works (unfortunately without an error message so I had to validate that behaviour with a debugger). Other people will likely be hit by other differences between 1.2.3 and 1.3.0. I made this "Blocker" because the unavailability of version-aligned documentation for anybody who doesn't use 1.3.0-alpha is potentially blocking their development work. Feel free to adjust priority if this is inappropriate. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0