- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1410) Make com.sun.mail:javax.mail optional
by QOS.CH (JIRA) 11 Jun '18

11 Jun '18

Michael Osipov created LOGBACK-1410: --------------------------------------- Summary: Make com.sun.mail:javax.mail optional Key: LOGBACK-1410 URL: https://jira.qos.ch/browse/LOGBACK-1410 Project: logback Issue Type: Improvement Components: logback-classic Affects Versions: 1.3.0-alpha4 Environment: Logback by default depends on {{com.sun.mail:javax.mail:jar}} while most people might never use the {{SMTPAppender}}. This dependency should marked {{optional}}. Reporter: Michael Osipov Assignee: Logback dev list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1409) Compile and reuse a Pattern in FileFilterUtil.computeCurrentPeriodsHighestCounterValue(String)
by QOS.CH (JIRA) 08 Jun '18

08 Jun '18

Andy Wilkinson created LOGBACK-1409: --------------------------------------- Summary: Compile and reuse a Pattern in FileFilterUtil.computeCurrentPeriodsHighestCounterValue(String) Key: LOGBACK-1409 URL: https://jira.qos.ch/browse/LOGBACK-1409 Project: logback Issue Type: Improvement Components: logback-core Affects Versions: 1.2.3 Reporter: Andy Wilkinson Assignee: Logback dev list Priority: Minor {{FileFilterUtil.filesInFolderMatchingStemRegex(String)}} currently calls {{String.matches(stemRegex)}} once for each file or directory in the folder. The is inefficient and noticeably so for folders with large numbers of files as it causes the same {{Pattern}} to be compiled once for each file or directory in the folder. The repeat compilation could be avoided by performing it once outside of the filtering callback: {code:java} Pattern pattern = Pattern.compile(stemRegex); return file.listFiles(new FilenameFilter() { @Override public boolean accept(File dir, String name) { return pattern.matcher(name).matches(); } }); {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1338) SizeAndTimeBasedRollingPolicy do not delete the old files
by QOS.CH (JIRA) 08 Jun '18

08 Jun '18

1 0

[JIRA] (LOGBACK-1408) Reconfigure with scan feature ignores changes made to JoranConfigurator
by QOS.CH (JIRA) 07 Jun '18

07 Jun '18

Eyal Roth created LOGBACK-1408: ---------------------------------- Summary: Reconfigure with scan feature ignores changes made to JoranConfigurator Key: LOGBACK-1408 URL: https://jira.qos.ch/browse/LOGBACK-1408 Project: logback Issue Type: Bug Affects Versions: 1.1.7 Reporter: Eyal Roth Assignee: Logback dev list Whatever changes made problematically to {{JoranConfigurator}} prior to loading the configuration are being ignored by the re-configuration introduced in the "scan" feature. The code at {{ReconfigureOnChangeTask}} creates a new configurator and also resets the context, which may contain some desired settings for the configurations - say, substitution properties discovered only at runtime. The official documentation [clearly states|https://logback.qos.ch/manual/configuration.html#joranDirectly] that modifying the configurator manually is a valid way to go with, so this is why this is considered a bug IMHO. I'm seeing multiple issues which are most likely related to this problem: LOGBACK-485, LOGBACK-592, LOGBACK-1059. I ended up dumping the scan feature and implementing on my own using Java's {{WatchService}} (LOGBACK-1073). -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1406) Seems all threads blocked
by QOS.CH (JIRA) 07 Jun '18

07 Jun '18

1 0

[JIRA] (LOGBACK-1394) Sometimes TimeBasedRollingPolicy & LogbackLock deadlock at 23:59:59
by QOS.CH (JIRA) 07 Jun '18

07 Jun '18

1 0

[JIRA] (LOGBACK-1407) Document when groovy support with Java 9+ is expected
by QOS.CH (JIRA) 31 May '18

31 May '18

Troy Daniels created LOGBACK-1407: ------------------------------------- Summary: Document when groovy support with Java 9+ is expected Key: LOGBACK-1407 URL: https://jira.qos.ch/browse/LOGBACK-1407 Project: logback Issue Type: Improvement Components: logback-core Affects Versions: 1.3.0-alpha4 Environment: Java 9 Reporter: Troy Daniels Assignee: Logback dev list The current logbook does not support groovy configuration files. This is fairly well documented. It also appears that this is temporary. I am unable to find any indication of when groovy support is expected to be restored. If it is expected to be in a week or two, I will wait for that and not rewrite by config file in XML. If it is months or years, I will need to rewrite them. It is certainly possible that restoring support requires an update to groovy. In that case, clear documentation of what changes are needed in groovy, ideally with links to the corresponding issues in the groovy project, would be helpful. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1406) Seems all threads blocked
by QOS.CH (JIRA) 31 May '18

31 May '18

Tony Zeng created LOGBACK-1406: ---------------------------------- Summary: Seems all threads blocked Key: LOGBACK-1406 URL: https://jira.qos.ch/browse/LOGBACK-1406 Project: logback Issue Type: Bug Components: logback-core Environment: Linux ubuntu-100 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux java version "1.8.0_161" Java(TM) SE Runtime Environment (build 1.8.0_161-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode) Reporter: Tony Zeng Assignee: Logback dev list Attachments: dump We are using `logback-core-1.1.11` as our logging framework, and recently we found sometimes our web application is blocked and no response. After thread dump, we found that most of web threads (and many, around 150) are waiting for a lock in `OutputStreamAppender` as following stacktrace show: {code:java} "qtp956480812-17384" #17384 prio=5 os_prio=0 tid=0x00007f667400e800 nid=0x43f3 waiting on condition [0x00007f652d4d0000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000843211e8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:210) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:414) at ch.qos.logback.classic.Logger.info(Logger.java:587) at cn.superid.auth.utils.PermissionUtil.hasPermission(PermissionUtil.java:31) {code} And following is the only thread which has the lock {code:java} "qtp956480812-17230" #17230 prio=5 os_prio=0 tid=0x00007f65c0017800 nid=0x4359 runnable [0x00007f65e5fe9000] java.lang.Thread.State: RUNNABLE at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:122) - locked <0x00000000830542d0> (a java.io.BufferedOutputStream) at java.io.PrintStream.write(PrintStream.java:480) - locked <0x00000000830542b0> (a java.io.PrintStream) at java.io.FilterOutputStream.write(FilterOutputStream.java:97) at ch.qos.logback.core.joran.spi.ConsoleTarget$1.write(ConsoleTarget.java:37) at ch.qos.logback.core.encoder.LayoutWrappingEncoder.doEncode(LayoutWrappingEncoder.java:131) at ch.qos.logback.core.OutputStreamAppender.writeOut(OutputStreamAppender.java:187) at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:212) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:414) at ch.qos.logback.classic.Logger.info(Logger.java:587) {code} >From the stacktrace, it seems no deadlock and application should not be blocked. But the actual phenomenon is no log, no response. So, what's the problem? If you need more info, let me know. Thanks. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 11 Early Access build 15 is available for download.
by Rory O'Donnell 29 May '18

29 May '18

Hi Ceki, **JDK 11 EA build 15 , *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. ** * * Newly approved Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o http://jdk.java.net/11/changes *Notable changes in JDK 11 EA builds since last email:* * b15 - JDK-8201627 <http://bugs.openjdk.java.net/browse/JDK-8201627> - Kerberos sequence number issues * b13 - JDK-8200146 <http://bugs.openjdk.java.net/browse/JDK-8200146> - Removal of appletviewer launcher o deprecated in JDK 9 and has been removed in this release * b13 - JDK-8201793 <http://bugs.openjdk.java.net/browse/JDK-8201793> - java.lang.ref.Reference does not support cloning ** ** JEPs proposed to target JDK 11 (review ends 2018/05/31 23:00 UTC) 330: Launch Single-File Source-Code Programs <http://openjdk.java.net/jeps/330> JEPs targeted to JDK 11, so far 309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309> 318: Epsilon: A No-Op Garbage Collector <http://openjdk.java.net/jeps/318> 320: Remove the Java EE and CORBA Modules <http://openjdk.java.net/jeps/320> 321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321> 323: Local-Variable Syntax for Lambda Parameters <http://openjdk.java.net/jeps/323> 324: Key Agreement with Curve25519 and Curve448 <http://openjdk.java.net/jeps/324> 327: Unicode 10 <http://openjdk.java.net/jeps/327> 328: Flight Recorder <http://openjdk.java.net/jeps/328> 329: ChaCha20 and Poly1305 Cryptographic Algorithms <http://openjdk.java.net/jeps/329> Finally, Initial TLSv1.3 implementation Released to the Open Sandbox. Please note well: this branch is under very active development and is not final by any means. Also note: by releasing this code, we are not committing a specific release or timeframe. We will continue development and fixing bugs until the code is ready for inclusion in the JDK. We welcome your feedback, more info [1] Regards, Rory [1] http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

1 0

[JIRA] (LOGBACK-1405) Ability to truncate existing files in SizeAndTimeBasedRollingPolicy
by QOS.CH (JIRA) 29 May '18

29 May '18

Gili created LOGBACK-1405: ----------------------------- Summary: Ability to truncate existing files in SizeAndTimeBasedRollingPolicy Key: LOGBACK-1405 URL: https://jira.qos.ch/browse/LOGBACK-1405 Project: logback Issue Type: Improvement Components: logback-core Reporter: Gili Assignee: Logback dev list Priority: Minor When debugging my software I want to flush log files on every run. Consider adding an "append" option to {{SizeAndTimeBasedRollingPolicy}} with the same meaning as "append" found in {{FileAppender.}} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0