- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1762) SizeAndTimeBasedRollingPolicy not deleting log files at all
by logback developers list 16 Aug '23

16 Aug '23

1 0

[JIRA] (LOGBACK-1762) SizeAndTimeBasedRollingPolicy not deleting log files at all
by logback developers list 16 Aug '23

16 Aug '23

1 0

[JIRA] (LOGBACK-1762) SizeAndTimeBasedRollingPolicy not deleting log files at all
by logback developers list 16 Aug '23

16 Aug '23

1 0

[JIRA] Updates for LOGBACK-1762: SizeAndTimeBasedRollingPolicy not deleting log files at all
by logback developers list 16 Aug '23

16 Aug '23

logback / LOGBACK-1762 [Open] SizeAndTimeBasedRollingPolicy not deleting log files at all ============================== 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-1762 ============================== Issue created ------------------------------ Neha Sahni created this issue on 16/Aug/23 9:16 Summary: SizeAndTimeBasedRollingPolicy not deleting log files at all Issue Type: Bug Affects Versions: 1.2.2, 1.2.8 Assignee: Logback dev list Components: logback-core Created: 16/Aug/23 9:16 Labels: SizeAndTimeBasedRollingPolicy archiveRemover Priority: Major Reporter: Neha Sahni Description: I have tried using logback version 1.2.2 and 1.2.8 with slf4j version of 1.7.21 The log files are not deleting as per the SizeAndTimeBasedRollingPolicy settings <configuration scan="true" scanPeriod="60 seconds"> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs/application.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>logs/application_%d\{yyyy-MM-dd}.%i.log.zip</fileNamePattern> <maxHistory>14</maxHistory> <totalSizeCap>5GB</totalSizeCap> <maxFileSize>15MB</maxFileSize> </rollingPolicy> When I tried to debug TimeBasedArchiveRemover class of logback core, I can see in method cleanPeriod() the files to be deleted are correctly identified and the code tries to delete them but file.delete returns false due to "The process cannot access the file because it is being used by another process." And when I checked more on which process can be holding the files, it gives the process Id of my java application itself. Not sure what exactly is holding these files and not letting logback delete them ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1761) Logback 1.4.8 -> 1.4.10 breaks Spring Boot 3.1.2
by logback developers list 10 Aug '23

10 Aug '23

1 0

[JIRA] (LOGBACK-1761) Logback 1.4.8 -> 1.4.10 breaks Spring Boot 3.1.2
by logback developers list 10 Aug '23

10 Aug '23

1 0

[JIRA] Updates for LOGBACK-1761: Logback 1.4.8 -> 1.4.10 breaks Spring Boot 3.1.2
by logback developers list 10 Aug '23

10 Aug '23

logback / LOGBACK-1761 [Open] Logback 1.4.8 -> 1.4.10 breaks Spring Boot 3.1.2 ============================== 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-1761 ============================== Issue created ------------------------------ Garret Wilson created this issue on 10/Aug/23 17:30 Summary: Logback 1.4.8 -> 1.4.10 breaks Spring Boot 3.1.2 Issue Type: Bug Assignee: Logback dev list Components: logback-core Created: 10/Aug/23 17:30 Priority: Critical Reporter: Garret Wilson Description: I am using this just-release {{com.globalmentor:globalmentor-root:0.8.16}} POM as a parent: https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml . It sets the {{logback.version}} Maven property to {{1.4.10}}, and then puts some Logback artifacts under dependency management. {code:xml} <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-access</artifactId> <version>${logback.version}</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>${logback.version}</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>${logback.version}</version> </dependency> {code} (Unfortunately Logback doesn't have a BOM; see SLF4J-437.) In my child POM I am using Spring Boot, with {{spring.boot.version}} similarly set to {{3.1.2}} in the parent POM: {code:xml} <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>${spring.boot.version}</version> <type>pom</type> <scope>import</scope> </dependency> {code} This all means that I am using Spring Boot 3.1.2, but pulling in {{logback-access}}, {{logback-classic}}, and {{logback-core}} at v1.4.10 to override the v1.4.8 brought in by {{spring-boot-starter-logging}}. Unfortunately when I run a Spring Boot application it gives me: {noformat} Exception in thread "main" java.lang.AbstractMethodError: Receiver class org.springframework.boot.logging.logback.RootLogLevelConfigurator does not define or inherit an implementation of the resolved method 'abstract ch.qos.logback.classic.spi.Configurator$ExecutionStatus configure(ch.qos.logback.core.Context)' of interface ch.qos.logback.classic.spi.Configurator. at ch.qos.logback.classic.util.ContextInitializer.invokeConfigure(ContextInitializer.java:122) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:87) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:65) at ch.qos.logback.classic.spi.LogbackServiceProvider.initializeLoggerContext(LogbackServiceProvider.java:52) at ch.qos.logback.classic.spi.LogbackServiceProvider.initialize(LogbackServiceProvider.java:41) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:183) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:170) at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:455) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:441) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:390) at org.apache.commons.logging.LogAdapter$Slf4jAdapter.createLocationAwareLog(LogAdapter.java:121) at org.apache.commons.logging.LogAdapter.createLog(LogAdapter.java:95) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:67) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:59) at org.springframework.boot.SpringApplication.<clinit>(SpringApplication.java:185) at ….main(….java:27) {noformat} This tells me there is at least one of two problems going on: * Logback 1.4.10 is incompatible with Spring Boot 3.1.2, and/or * Something in {{logback-access}}, {{logback-classic}}, and {{logback-core}} at v1.4.10 depends on some other Logback artifact I missed, which is still set out v1.4.8 because of Spring Boot. (I wouldn't have this second doubt if there was a Logback BOM.) You will know better than me what changed between Logback v1.4.8 and v1.4.10 that might be causing this message, or that might depend on some other updated Logback artifact. For now I will set {{logback.version}} back to {{1.4.8}} so the program will run, but this seems pretty urgent to address, either by fixing the incompatibility, or by providing a BOM to ensure that all artifacts are updated in sync. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for LOGBACK-1760: Variable (property) substitution in include file
by logback developers list 03 Aug '23

03 Aug '23

logback / LOGBACK-1760 [Open] Variable (property) substitution in include file ============================== 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-1760 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 03/Aug/23 14:49 Summary: Variable (property) substitution in include file Issue Type: Sub-task Affects Versions: 1.3.8, 1.4.8 Assignee: Logback dev list Components: Joran Created: 03/Aug/23 14:49 Fix Versions: 1.3.9, 1.4.9 Priority: Major Reporter: Ceki Gülcü ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] (LOGBACK-1756) Change LoggerContext to use MDCAdapter instead of LogbackMDCAdapter
by logback developers list 28 Jul '23

28 Jul '23

1 0

Setting MDCAdapter
by logback developers list 27 Jul '23

27 Jul '23

Hi, I've come across this issue recently https://github.com/line/armeria/issues/5045 where Armeria tries to set a non-thread-local MDCAdapter. This broke in logback 1.4.8 where MDCAdapter is created at logger creation time. Was wondering if there's something to fix in Logback to make this possible without a hacky workaround? Thanks, Ric Mariano

1 0