August 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-1279) Async appenders do not scale well across multiple threads
by QOS.CH (JIRA) 31 Aug '18

31 Aug '18

1 0

[JIRA] (LOGBACK-1417) Better error reporting than IllegalArgumentException, All tokens consumes but was expecting "}"
by QOS.CH (JIRA) 29 Aug '18

29 Aug '18

Ceki Gülcü created LOGBACK-1417: ----------------------------------- Summary: Better error reporting than IllegalArgumentException, All tokens consumes but was expecting "}" Key: LOGBACK-1417 URL: https://jira.qos.ch/browse/LOGBACK-1417 Project: logback Issue Type: Improvement Components: logback-core Environment: To reproduce: case 1) define a pattern with no ending }. case 2) define a pattern in property and refer to it in a Layout, also pattern with no ending } Reporter: Ceki Gülcü Assignee: Logback dev list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1192) Stuck Thread Issue due to file system got full with logs
by QOS.CH (JIRA) 25 Aug '18

25 Aug '18

1 0

[JIRA] (LOGBACK-1416) cann't delete the history log base on periodtype hour after system start
by QOS.CH (JIRA) 25 Aug '18

25 Aug '18

yanwuhua created LOGBACK-1416: --------------------------------- Summary: cann't delete the history log base on periodtype hour after system start Key: LOGBACK-1416 URL: https://jira.qos.ch/browse/LOGBACK-1416 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Environment: suse linux Reporter: yanwuhua Assignee: Logback dev list # log setting:<appender name="DebugAppender" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>$\{loggerHome}/logs/$\{moduleName}/debug/$\{moduleName}_debug.log</file> <append>true</append> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>$\{loggerHome}/logs/$\{moduleName}/debug/$\{moduleName}_debug_%d\{{color:#d04437}yyyyMMddHH{color}}_%i.log</fileNamePattern> <maxHistory>2</maxHistory> {color:#d04437} <CleanHistoryOnStart>true</CleanHistoryOnStart>{color} <maxFileSize>100MB</maxFileSize> </rollingPolicy> <encoder charset="UTF-8"> <pattern>%d\{yyyy-MM-dd HH:mm:ss.SSS}|%-5level|[%thread]|%m%n%</pattern> </encoder> </appender> # after set the CleanhistoryOnStart to true, the history log cann't be deleted base on the rule. # debugging the code,find the issue :ch.qos.logback.core.rolling.helper.RollingCalendar public long periodBarriersCrossed(long start, long end) \{ if (start > end) throw new IllegalArgumentException("Start cannot come before end"); long startFloored = getStartOfCurrentPeriodWithGMTOffsetCorrection(start, getTimeZone()); long endFloored = getStartOfCurrentPeriodWithGMTOffsetCorrection(end, getTimeZone()); long diff = endFloored - startFloored; switch (periodicityType) \{ case TOP_OF_MILLISECOND: return diff; case TOP_OF_SECOND: return diff / MILLIS_IN_ONE_SECOND; case TOP_OF_MINUTE: return diff / MILLIS_IN_ONE_MINUTE; {color:#d04437}case TOP_OF_HOUR:{color} {color:#d04437} return (int) diff / MILLIS_IN_ONE_HOUR;{color} case TOP_OF_DAY: return diff / MILLIS_IN_ONE_DAY; case TOP_OF_WEEK: return diff / MILLIS_IN_ONE_WEEK; case TOP_OF_MONTH: return diffInMonths(start, end); default: throw new IllegalStateException("Unknown periodicity type."); } } the red color code will return the number below 0. because covert long to int . the value will be < 0. It's the reason why we cann't delete the history logs after system start -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1229) byte count for tomcat is wrong when transfer encoding is chunked
by QOS.CH (JIRA) 24 Aug '18

24 Aug '18

1 0

JDK 11: First Release Candidate available
by Rory O'Donnell 24 Aug '18

24 Aug '18

Hi Ceki, *JDK 11 build 28 is our first JDK 11 Release Candidate [1] * * JDK 11 Early Access build 28 is available at : - jdk.java.net/11/ *FOSS fixes in recent builds.* * Eclipse Jetty - JDK-8207177 <https://bugs.openjdk.java.net/browse/JDK-8207177> (b27) * Apache Tomcat -JDK-8208642 <https://bugs.openjdk.java.net/browse/JDK-8208642>(b27) * Netty - JDK-8207029 <https://bugs.openjdk.java.net/browse/JDK-8207029> (b23), JDK-8208166 <https://bugs.openjdk.java.net/browse/JDK-8208166> (b25) *JDK 12 Early Access build 8 is available at : - jdk.java.net/12/* * Release Notes for JDK 12 [2] * Changes in this build include o JDK-8208350 <https://bugs.openjdk.java.net/browse/JDK-8208350> - Disable all DES TLS cipher suites *OpenJFX Early-Access Build 24 is available at :-* *http://jdk.java.net/openjfx/* * This library is delivered as a set of modules, along with the native code needed to run JavaFX, that can be run using a JDK 10 <http://jdk.java.net/10/> build or a JDK 11 EA <http://jdk.java.net/11/> build. * This build is intended to allow application developers and OpenJFX contributors to test their applications with an unbundled, standalone JavaFX library. Regards, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001844.html <http://openjdk.java.net/projects/jdk/11/#Schedule> [2] http://jdk.java.net/12/release-notes -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (LOGBACK-995) Standalone rollover gets exception
by QOS.CH (JIRA) 23 Aug '18

23 Aug '18

1 0

[JIRA] (LOGBACK-204) file appender that rolls on startup
by QOS.CH (JIRA) 23 Aug '18

23 Aug '18

1 0

Compression of log files is omitted when application is stopped at rollover
by ch w 21 Aug '18

21 Aug '18

*Description:* There is a bug report <https://jira.qos.ch/browse/LOGBACK-914> 4 years ago. It's not fixed yet. It occurs to me now. This is my configuration: > <rollingPolicy > class="ch.qos.logback.core.rolling.MyTimeBasedRollingPolicy"> > > <fileNamePattern>${baseLogPath}/logs/app.%d{yyyy-MM-dd}.log.gz</fileNamePattern> > </rollingPolicy> The log file will roll and compress at midnight normally. but, the compression is omitted if the application is not running at rolling time . The application will restart manually at next day , but the elapsed log file will not be compressed. *Solution:* I have an idea and have put it into practice to fix this problem. I add a property, say compressElapsedPeriodFileOnStart , to TimeBasedRollingPolicy ,default true. It compress the elapsed period log file, as below : 1 calculate the rolling period 2. generate the elapsed period log file name 3. compress it It works well for me, there is a better way ? I will push a PR if no.

1 0