January 2019 - 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-1456) Update Java EE dependencies
by QOS.CH (JIRA) 30 Jan '19

30 Jan '19

Gili created LOGBACK-1456: ----------------------------- Summary: Update Java EE dependencies Key: LOGBACK-1456 URL: https://jira.qos.ch/browse/LOGBACK-1456 Project: logback Issue Type: Improvement Components: logback-access Affects Versions: 1.3.0-alpha4 Reporter: Gili Assignee: Logback dev list Please update all Java EE dependencies per [https://wiki.eclipse.org/New_Maven_Coordinates] otherwise users who depend on slf4j and logback will be unable to update the dependencies on their end. For example, if you depend on the old coordinates and someone attempts to "upgrade" the dependency version by depending on the new coordinates with the higher version number then both versions (with the old and new coordinates) will get pulled in as dependencies. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1194) scanPeriod attribute is required by logback-classic for auto-reload to work
by QOS.CH (JIRA) 28 Jan '19

28 Jan '19

1 0

[JIRA] (LOGBACK-1303) Wrong delimiter in pattern layout for ISO 8601
by QOS.CH (JIRA) 27 Jan '19

27 Jan '19

1 0

[JIRA] (LOGBACK-1455) When log file index is greater than 1000, the old files will no longger be deleted
by QOS.CH (JIRA) 27 Jan '19

27 Jan '19

Raven created LOGBACK-1455: ------------------------------ Summary: When log file index is greater than 1000, the old files will no longger be deleted Key: LOGBACK-1455 URL: https://jira.qos.ch/browse/LOGBACK-1455 Project: logback Issue Type: Bug Reporter: Raven Assignee: Logback dev list My config file just like this: {color:#e8bf6a}<appender {color}{color:#bababa}name{color}{color:#e6db74}="FILE_VERBOSE" {color}{color:#bababa}class{color}{color:#e6db74}="ch.qos.logback.core.rolling.RollingFileAppender"{color}{color:#e8bf6a}> {color}{color:#e8bf6a} <file>{color}$\{LOG_HOME}/app.log{color:#e8bf6a}</file> {color}{color:#e8bf6a} <encoder> {color}{color:#e8bf6a} <charset>{color}UTF-8{color:#e8bf6a}</charset> {color}{color:#e8bf6a} <pattern>{color}%d\{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger\{36} - %msg%n{color:#e8bf6a}</pattern> {color}{color:#e8bf6a} </encoder> {color}{color:#e8bf6a} <rollingPolicy {color}{color:#bababa}class{color}{color:#e6db74}="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"{color}{color:#e8bf6a}> {color}{color:#e8bf6a} <fileNamePattern>{color}$\{LOG_HOME}/app.%d\{yyyy-MM-dd}.%i.log{color:#e8bf6a}</fileNamePattern> {color}{color:#e8bf6a} <maxHistory>{color}5{color:#e8bf6a}</maxHistory> {color}{color:#e8bf6a} <totalSizeCap>{color}100MB{color:#e8bf6a}</totalSizeCap> {color}{color:#e8bf6a} <timeBasedFileNamingAndTriggeringPolicy {color}{color:#bababa}class{color}{color:#e6db74}="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"{color}{color:#e8bf6a}> {color}{color:#e8bf6a} <maxFileSize>{color}10MB{color:#e8bf6a}</maxFileSize> {color}{color:#e8bf6a} </timeBasedFileNamingAndTriggeringPolicy> {color}{color:#e8bf6a} </rollingPolicy> {color}{color:#e8bf6a}</appender>{color} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-793) Logback RollingFileAppender error when trying to do manual rollover
by QOS.CH (JIRA) 21 Jan '19

21 Jan '19

1 0

[JIRA] (LOGBACK-632) Add timeout attribute to SMTP appender
by QOS.CH (JIRA) 21 Jan '19

21 Jan '19

1 0

[JIRA] (LOGBACK-632) Add timeout attribute to SMTP appender
by QOS.CH (JIRA) 21 Jan '19

21 Jan '19

1 0

JDK 12 enters Rampdown Phase Two
by Rory O'Donnell 21 Jan '19

21 Jan '19

Hi Ceki, **OpenJDK builds *- JDK 12 Early Access build 28 **is now available **at : - jdk.java.net/12/* * Per the JDK 12 schedule [1], we are now in Rampdown Phase Two. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. o Per the JDK Release Process [3] we now turn our focusto P1 and P2 bugs. **OpenJDK builds *- JDK 13 Early Access build 4 is **now available **at : - jdk.java.net/13/* * These early-access, open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Release Notes: o http://jdk.java.net/13/release-notes * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B3%22%3A%3A…> Blog Updates from Java SE Product Management since last email. * Oracle Java SE Releases FAQ [3] * Oracle Java SE Support Roadmap [4] Rgds,Rory [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2019-January/002537.html [3] https://blogs.oracle.com/java-platform-group/oracle-java-se-releases-faq [4] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (LOGBACK-1454) StackOverflow error
by QOS.CH (JIRA) 17 Jan '19

17 Jan '19

1 0