- logback-dev - mailman3.qos.ch

[qos-ch/logback-decoder] c4d388: Bump logback-core from 1.0.13 to 1.2.0
by dependabot[bot] 07 Jun '21

07 Jun '21

Branch: refs/heads/dependabot/maven/ch.qos.logback-logback-core-1.2.0 Home: https://github.com/qos-ch/logback-decoder Commit: c4d38849a9dd512029fb7d96cbb9e9c1b22425be https://github.com/qos-ch/logback-decoder/commit/c4d38849a9dd512029fb7d96cb… Author: dependabot[bot] <49699333+dependabot[bot](a)users.noreply.github.com> Date: 2021-06-07 (Mon, 07 Jun 2021) Changed paths: M pom.xml Log Message: ----------- Bump logback-core from 1.0.13 to 1.2.0 Bumps logback-core from 1.0.13 to 1.2.0. --- updated-dependencies: - dependency-name: ch.qos.logback:logback-core dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support(a)github.com>

1 0

[JIRA] Updates for LOGBACK-1560: Allow ServerAdapter customization in LogbackValve
by QOS.CH (JIRA) 27 May '21

27 May '21

logback / LOGBACK-1560 [Open] Allow ServerAdapter customization in LogbackValve ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1560 ============================== Issue created ------------------------------ Alexey created this issue on 27/May/21 12:33 PM Summary: Allow ServerAdapter customization in LogbackValve Issue Type: Improvement Assignee: Logback dev list Components: logback-access Created: 27/May/21 12:33 PM Environment: ch.qos.logback.access.tomcat.LogbackValve Priority: Minor Reporter: Alexey Description: Currently in LogbackValve#invoke we have: {code:java} TomcatServerAdapter adapter = new TomcatServerAdapter(request, response); IAccessEvent accessEvent = new AccessEvent(request, response, adapter); {code} but it's useful to have possibility to customize TomcatServerAdapter, so it's helpful to move TomcatServerAdapter creation to a protected method so it will be possible to override TomcatServerAdapter creation. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1559: Improve subAppend function in OutputStreamAppender
by QOS.CH (JIRA) 26 May '21

26 May '21

logback / LOGBACK-1559 [Open] Improve subAppend function in OutputStreamAppender ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1559 ============================== Issue created ------------------------------ Akshay Patidar created this issue on 26/May/21 10:34 AM Summary: Improve subAppend function in OutputStreamAppender Issue Type: Improvement Assignee: Logback dev list Components: logback-core Created: 26/May/21 10:34 AM Priority: Major Reporter: Akshay Patidar Description: Currently, if we want to write a custom appender on top of OutputStreamAppender we have to override *subAppend(E event)* [code|[https://github.com/qos-ch/logback/blob/master/logback-core/src/main/j…] from OutputStreamAppender which is not desirable as then we have to keep track of changes made in the OutputStreamAppender and update our custom appender accordingly. To avoid this we can replace [these|https://github.com/qos-ch/logback/blob/master/logback-core/src/main/j…] lines with the *writeOut(event)* method. Now if someone wants to extend OutputStreamAppender he can just override *writeOut* method. Also, the *writeBytes* method in OutputStreamAppender is private so we have to copy the function in our appender which is not desirable. (We can make *writeBytes* protected for this) ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

JDK 17 Early Access build 23 is available
by Rory O'Donnell 21 May '21

21 May '21

Hi Ceki, ** *OpenJDK 17 Early Access build 23 is now available at *_*https://jdk.java.net/17* <https://jdk.java.net/17>_ * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html> * JEPs targeted to JDK 17, so far: o JEP 356: _Enhanced Pseudo-Random Number Generators <https://openjdk.java.net/jeps/356>_ o JEP 382: _New macOS Rendering Pipeline <https://openjdk.java.net/jeps/382>_ o JEP 391: _macOS/AArch64 Port <https://openjdk.java.net/jeps/391>_ o JEP 398: _Deprecate the Applet API for Removal <https://openjdk.java.net/jeps/398>_ o JEP 409: _Sealed Classes <https://openjdk.java.net/jeps/409>_ o JEP 410: _Remove the Experimental AOT and JIT Compiler <https://openjdk.java.net/jeps/410>_ o JEP 412: _Foreign Function & Memory API (Incubator) <https://openjdk.java.net/jeps/412>_ o JEP 414: _Vector API (Second Incubator) <https://openjdk.java.net/jeps/414>_ * Release Notes are available at _https://jdk.java.net/17/release-notes <https://jdk.java.net/17/release-notes>_ * Changes in recent builds that maybe of interest: o Build 23 + JDK-8243287: Removal of Unsafe::defineAnonymousClass. o Build 22 + *JDK-8266369: New implementation of java.nio.channels.Selector on Microsoft Windows. * o Build 21 + *JDK-8196415: JARs signed with SHA-1 algorithms are restricted by default.* + *JDK-8266858: macOS on ARM early access available.* # The ARM port should behave similarly to the Intel port. There are no known feature differences. # When reporting issues on macOS please specify if using ARM or x64. *We need your help in testing new Selector implementation on Windows [1]:* * The implementation of the Selector API on Windows has been replaced in JDK 17 b22 with a new more scalable implementation [2]. * The old select based Selector implementation has been the default since Java 1.4 (2002) so replacing it is a significant change. * It would be really helpful to get more testing of the new implementation before the fork for Rampdown Phase One on June 10th. *Other Topics which might be of Interest:* * Updates to JEP 411: Deprecate the Security Manager for Removal | _Link_ <https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005569.html> * "The meaning, or not, of “LTS” | _Link_ <https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005543.html> * JFR Remote Recording Stream | _Link_ <https://egahlin.github.io/2021/05/17/remote-recording-stream.html> *Project Loom Early-Access Build: **_Build 17-loom+7-342_* <https://jdk.java.net/loom/>*(2021/5/11)* * These early-access builds are provided under the _GNU General Public License, version 2, with the Classpath Exception_ <https://openjdk.java.net/legal/gplv2+ce.html>. * These builds are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. * Please send feedback via e-mail to _loom-dev(a)openjdk.java.net <mailto:loom-dev@openjdk.java.net>_.To send e-mail to this address you must first _subscribe to the mailing list_ <https://mail.openjdk.java.net/mailman/listinfo/loom-dev>. *Project Panama Early-Access Build: *_*Build 17-panama+3-167* <https://jdk.java.net/panama/>_*(2021/5/18)* * These early-access builds are provided under the _GNU General Public License, version 2, with the Classpath Exception_ <https://openjdk.java.net/legal/gplv2+ce.html>. * This build is aimed at testing a prototype implementation of the foreign memory support, foreign function support and native extraction tooling from the "foreign-jextract" branch of the Panama repo. * Please send feedback via e-mail to _panama-dev(a)openjdk.java.net <mailto:panama-dev@openjdk.java.net>_. To send e-mail to this address you must first _subscribe to the mailing list_ <https://mail.openjdk.java.net/mailman/listinfo/panama-dev>. Rgds,Rory [1] _https://mail.openjdk.java.net/pipermail/nio-dev/2021-May/008988.html_ <https://mail.openjdk.java.net/pipermail/nio-dev/2021-May/008988.html> [2] _https://bugs.openjdk.java.net/browse/JDK-8266369_ <https://bugs.openjdk.java.net/browse/JDK-8266369> -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] Updates for LOGBACK-1558: Fix for code that fails existing tests
by QOS.CH (JIRA) 17 May '21

17 May '21

logback / LOGBACK-1558 [Open] Fix for code that fails existing tests ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1558 ============================== Issue created ------------------------------ Cezary Regec created this issue on 17/May/21 11:31 AM Summary: Fix for code that fails existing tests Issue Type: Improvement Affects Versions: 1.3.0-alpha6 Assignee: Logback dev list Components: logback-classic, logback-core Created: 17/May/21 11:31 AM Priority: Major Reporter: Cezary Regec Description: I have implemented a fix for the code that fails the following tests: * {color:#000000}ch.qos.logback.classic.joran{color}.JoranConfiguratorTest, * {color:#000000}{color:#000000}ch.qos.logback.core.rolling.helper.{color}{color}{color:#000000}RollingCalendarTest{color} {color:#000000}RollingCalendar had an issue when detecting collisions - there was a case when the first day of a year is not exactly within the first week of a year.{color} {color:#000000}JoranConfigurator did not correctly resolve appender refs (eg. AsyncAppenderBase was started too early, before all appenders were attached to it) and I delayed the start of appenders after the whole configuration is built.{color} {color:#000000}I have added a pull request with my fixes on GitHub.{color} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1033) Enable serialization of HTTP request attributes
by QOS.CH (JIRA) 15 May '21

15 May '21

1 0

[JIRA] (LOGBACK-1557) An exception is thrown when AbstractServerSocketAppender is being stopped
by QOS.CH (JIRA) 15 May '21

15 May '21

1 0

[JIRA] Updates for LOGBACK-1557: An exception is thrown when AbstractServerSocketAppender is being stopped
by QOS.CH (JIRA) 15 May '21

15 May '21

logback / LOGBACK-1557 [Open] An exception is thrown when AbstractServerSocketAppender is being stopped ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1557 ============================== Issue created ------------------------------ Cezary Regec created this issue on 15/May/21 3:11 PM Summary: An exception is thrown when AbstractServerSocketAppender is being stopped Issue Type: Bug Affects Versions: 1.0.13, 1.1.0, 1.1.1, 1.1.10, 1.1.11, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.1.7, 1.1.8, 1.1.9, 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.3.0-alpha0, 1.3.0-alpha1, 1.3.0-alpha3, 1.3.0-alpha4, 1.3.0-alpha5, 1.3.0-alpha6 Assignee: Logback dev list Components: logback-core Created: 15/May/21 3:11 PM Environment: Tested and this issue on: - macOS 10.13.16, MacBookPro8,2, Java 11 - Ubuntu 18.04, Java 8 and Java 11 Priority: Major Reporter: Cezary Regec Description: ServerSocketAppender (or any appender using {color:#000000}ConcurrentServerRunner) {color}can emit an error when stopping. This issue is most noticeable in projects where Spring Boot is used, as Spring Boot reloads Logback config when starting and any error that occured during this reload is escalated and crashes the whole app. *Symptomps*: An error containing the following message is being reported to StatusManager: {noformat} java.net.SocketException: Socket is closed{noformat} *How to reproduce?* I have added a simple tests that presents how to reproduce the error: [https://github.com/multicatch/logback/commit/97aa380c4318d09e688d96a3fd9873…] *The cause* This is due to the fact that ConcurrentServerRunner is not being interrupted when it is run by the ExecutionService and it waits for new connections even when it was instructed to stop. Finally, the ServerSocket is closed and the `accept()` method is still waiting for connections (and even if not, the loop in ConcurrentServerRunner is not breaking because the thread with the runner was not interrupted) and it causes the `SocketException`. It is then caught and added to StatusManager, and then crashes Spring Boot as this is treated as configuration error. I have implemented a fix for this issue ([https://github.com/multicatch/logback/tree/fix/server-socket-closing) and it can be cherry-picked to all affected versions. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1556) SizeAndTimeBasedRollingPolicy does not delete old files with MaxHistory
by QOS.CH (JIRA) 13 May '21

13 May '21

1 0

[JIRA] Updates for LOGBACK-1556: SizeAndTimeBasedRollingPolicy does not delete old files with MaxHistory
by QOS.CH (JIRA) 13 May '21

13 May '21

logback / LOGBACK-1556 [Open] SizeAndTimeBasedRollingPolicy does not delete old files with MaxHistory ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1556 ============================== Issue created ------------------------------ David Goichman created this issue on 13/May/21 9:05 AM Summary: SizeAndTimeBasedRollingPolicy does not delete old files with MaxHistory Issue Type: Bug Affects Versions: 1.3.0-alpha5 Assignee: Logback dev list Attachments: image-2021-05-13-10-02-35-819.png Components: logback-core Created: 13/May/21 9:05 AM Environment: <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>TRACE</level> </filter> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>${LOG_HOME}/%d\{yyyyMMdd}_agent_%i.log </fileNamePattern> <maxFileSize>16MB</maxFileSize> <maxHistory>1</maxHistory> <totalSizeCap>1GB</totalSizeCap> <historyAsFileCount>true</historyAsFileCount> <cleanHistoryOnStart>true</cleanHistoryOnStart> </rollingPolicy> <encoder> <pattern>${LOG_PATTERN}</pattern> </encoder> </appender> Labels: SizeAndTimeBasedRollingPolicy rollingFileappender Priority: Major Reporter: David Goichman Description: The policy will not delete files older than a month, and shows other inconsistent behavior. e.g. 20210429_agent_0.log will never be deleted. !image-2021-05-13-10-02-35-819.png! It will also sometimes not remove any files at all, as you can see from the rest of the logs from May <-> 05. To reproduce you can use the same policy as in the environment, and just copy and paste the same file as in the format with a date that goes a month or more back, they will not be removed. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0