December 2018 - logback-dev

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-1372) SizeAndTimeBasedRollingPolicy can't remove old logs files
by QOS.CH (JIRA) 19 Dec '18

19 Dec '18

1 0

JDK 12 enters Rampdown Phase One
by Rory O'Donnell 14 Dec '18

14 Dec '18

Hi Ceki, *JDK 12 Early Access build **is now available **at : - jdk.java.net/12/* * Per the JDK 12 schedule [1], we are now in Rampdown Phase One. 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 We’ve forked the main-line source repository, jdk/jdk, to the JDK 12 stabilization repository. Changes since the last availability email * JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental) <http://openjdk.java.net/jeps/189> moved to *Targeted*. * JEP 334: JVM Constants API <http://openjdk.java.net/jeps/334> moved to *Targeted*. * JEP 344: Abortable Mixed Collections for G1 <http://openjdk.java.net/jeps/344> moved to *Targeted*. * JEP 346: Promptly Return Unused Committed Memory from G1 <http://openjdk.java.net/jeps/346> to *Targeted*. * JEP 326: Raw String Literals <https://openjdk.java.net/jeps/326> (Preview) *Proposed to drop from JDK 12* o link to proposal on jdk-dev <https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html> Bug fixes reported by Open Source Projects : o JDK-8211051 - fixed in b22 - reported by JUnit5 o JDK-8211422 - fixed in b23 - reported by Apache Batik The Java Crypto Roadmap <https://java.com/cryptoroadmap> has been updated with the following target: * With the 2019-04-16 CPU, o Targeted Releases - JDK 12, JDK 11, JDK 8, and JDK 7 o Distrust TLS server certificates anchored by Symantec Root CAs. Oracle Java SE 8 Release Updates [3] * Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license. Rgds, Rory [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002405.html [3] https://java.com/en/download/release_notice.jsp -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (LOGBACK-1443) logback for java9 should export the package ch.qos.logback.core.rolling
by QOS.CH (JIRA) 13 Dec '18

13 Dec '18

1 0

[JIRA] (LOGBACK-1385) JPMS: exports ch.qos.logback.core.rolling
by QOS.CH (JIRA) 13 Dec '18

13 Dec '18

1 0

[JIRA] (LOGBACK-1446) Make property references escapable
by QOS.CH (JIRA) 09 Dec '18

09 Dec '18

Neon created LOGBACK-1446: ----------------------------- Summary: Make property references escapable Key: LOGBACK-1446 URL: https://jira.qos.ch/browse/LOGBACK-1446 Project: logback Issue Type: Improvement Components: logback-core Affects Versions: 1.3.0-alpha4, 1.2.3 Reporter: Neon Assignee: Logback dev list As you requested in my [PR|https://github.com/qos-ch/logback/pull/445#issuecomment-445518600] I created an account and issue for this matter. Short description from the pull request for searchability in JIRA: {panel} Currently it's not possible to escape strings like {{${some.property}}} in the logback.xml. This is escpecially problematic when trying to use a replacement command with named groups in the appender pattern. Therefore something like this will attempt to insert a property value instead of the named group: {{%replace(%msg){'(?<namedGroup>somestuffhere)', '${namedGroup}'}}}. I kept this example as simple (stupid) as possible for demonstration purposes since real world patterns where you need named groups often are pretty complex. {panel} As stated in my solution the implementation could be improved. Currently each of the characters {{$}}, {{{}}, {{:}} and {{}}} are affecting the token state even if the string doesn't represent a property reference, such as {{{test}}} or {{test:test}}. Maybe I'm missing something and the curly braces have a special meaning even without a preceding dollar sign, but otherwise the tokenizer could be more strict, so escaping would only need a single {{\}} in front of the dollar sign (like {{\${escaped}}}). -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1445) Joran's PropertySetter::addBasicProperty doesn't work when the basic property followsTheValueOfConvention
by QOS.CH (JIRA) 05 Dec '18

05 Dec '18

Steve Lessard created LOGBACK-1445: -------------------------------------- Summary: Joran's PropertySetter::addBasicProperty doesn't work when the basic property followsTheValueOfConvention Key: LOGBACK-1445 URL: https://jira.qos.ch/browse/LOGBACK-1445 Project: logback Issue Type: Bug Components: Joran Affects Versions: 1.3.0-alpha4 Reporter: Steve Lessard Assignee: Logback dev list The Joran code for supporting custom properties goes to great lengths to ensure that a basic property can be created from a string. In particular Joran supports basic properties where the type of the property is a class containing a `public static valueOf(String str)`. Joran will go through lots of checks before creating an instance of this class (via the valueOf) method and then, at the last second, not use that class instance at all and try to call the property setter with the original string. Naturally, since the setter is expecting specific class instance and not a String instance the call fails with an InvalidArgumentException. The fix is actually quite simple and is contained in this pull request: https://github.com/qos-ch/logback/pull/442 -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1312) Tomcat 8.5.14 reports stale thread created by Logback
by QOS.CH (JIRA) 03 Dec '18

03 Dec '18

1 0

[JIRA] (LOGBACK-1444) Add option for SMTP headers
by QOS.CH (JIRA) 03 Dec '18

03 Dec '18

Michael Osipov created LOGBACK-1444: --------------------------------------- Summary: Add option for SMTP headers Key: LOGBACK-1444 URL: https://jira.qos.ch/browse/LOGBACK-1444 Project: logback Issue Type: Improvement Components: logback-core Affects Versions: 1.3.0-alpha4 Reporter: Michael Osipov Assignee: Logback dev list I'd like to add arbitrary SMTP headers to an email, e.g., {{X-Priority}}. A {{<headers />}} just like {{<filters />}} would be nice. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1443) logback for java9 should export the package ch.qos.logback.core.rolling
by QOS.CH (JIRA) 02 Dec '18

02 Dec '18

Thomas Kläger created LOGBACK-1443: -------------------------------------- Summary: logback for java9 should export the package ch.qos.logback.core.rolling Key: LOGBACK-1443 URL: https://jira.qos.ch/browse/LOGBACK-1443 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.3.0-alpha4 Environment: Java 9 and later Reporter: Thomas Kläger Assignee: Logback dev list To allow custom implementations of the interfaces in `ch.qos.logback.core.rolling` (like `TriggeringPolicy`, `RollingPolicy`, `TimeBasedFileNamingAndTriggeringPolicy` and its base implementation classes) need to be accessible for other modules. To resolve this issue, the module-info.java file should include the line {{exports ch.qos.logback.core.rolling}} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0