December 2021 - logback-dev

[JIRA] (LOGBACK-1591) Possibility of vulnerability - registered as CVE-2021-42550
by QOS.CH (JIRA) 21 Dec '21

21 Dec '21

1 0

[JIRA] Updates for LOGBACK-1600: Re-create log if it gets deleted at runtime on Unix/Linux
by QOS.CH (JIRA) 21 Dec '21

21 Dec '21

logback / LOGBACK-1600 [Open] Re-create log if it gets deleted at runtime on Unix/Linux ============================== 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-1600 ============================== Issue created ------------------------------ junmoKang created this issue on 21/Dec/21 2:51 AM Summary: Re-create log if it gets deleted at runtime on Unix/Linux Issue Type: Improvement Affects Versions: 1.2.0 Assignee: Logback dev list Components: logback-core Created: 21/Dec/21 2:51 AM Environment: CentOS-7 window 10 logback-core 1.2.0 logback-classic-1.2.0 Priority: Major Reporter: junmoKang Description: in logback version 1.1.2~1.1.9, it re-creates log files when get deleting at runtime on Unix/Linux. It works normally. I used logback version 1.1.2, and I saw this article and applied this my project using logback. https://jira.qos.ch/browse/LOGBACK-1004 But, I upgraded version 1.1.2 -> 1.2.9 and it did not re create log files when it gets deleted at runtime on Unix/Linux. I think it's because FileAppender class's writeOut method not invoked. FileAppender class's writeOut method overrieds OutputStreamAppender class's writeOut method. I saw this news from the logback's news. h3. February 8th, 2017, Release of version 1.2.0 h4. {{Encoder}} interface has changed and is no longer expected to handle an {{OutputStream}}. {{Encoder}} interface has changed and is no longer expected to handle an {{OutputStream}}. This simplification allows finer-grain locking resulting in [significantly improved performance|https://docs.google.com/spreadsheets/d/1cpb5D7qnyye4W0RTlHUnXed…] Exactly, from logback version 1.2.0, it did not Re-create log if it gets deleted at runtime on Unix/Linux, because FileAppender class's writeOut method not invoked. I don't know why it is. this is my code's segment. I don't use logback.xml. Logger root = (Logger) LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME); LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory() TimeBasedRollingPolicy<ILoggingEvent> timePolicy = new TimeBasedRollingPolicy<ILoggingEvent>(); timePolicy.setContext(context); WorldWritableFileAppender<ILoggingEvent> rollingFileAppender = new WorldWritableFileAppender<ILoggingEvent>(); timePolicy.setParent(rollingFileAppender); timePolicy.setFileNamePattern(logDir + "/" + fileNamePattern + "-" + product + "_%i.log." + compressFormat); timePolicy.setMaxHistory(maxHistory); timePolicy.setCleanHistoryOnStart(false); timePolicy.start(); SizeAndTimeBasedFNATP<ILoggingEvent> sizePolicy = new SizeAndTimeBasedFNATP<ILoggingEvent>(); sizePolicy.setContext(context); sizePolicy.setMaxFileSize(FileSize.valueOf(maxFileSize)); sizePolicy.setTimeBasedRollingPolicy(timePolicy); sizePolicy.start(); timePolicy.setTimeBasedFileNamingAndTriggeringPolicy(sizePolicy); timePolicy.start(); rollingFileAppender.setTriggeringPolicy(sizePolicy); rollingFileAppender.setRollingPolicy(timePolicy); PatternLayoutEncoder pl = new PatternLayoutEncoder(); pl.setContext(context); pl.setPattern(pattern); pl.start(); rollingFileAppender.setEncoder(pl); rollingFileAppender.start(); root.addAppender(rollingFileAppender); public class WorldWritableFileAppender<E> extends RollingFileAppender<E>{ private File file_ptr; @Override public void openFile(String file_name) throws IOException { if(file_name != null) { File file = new File(file_name); file_ptr = file; if (FileUtil.createMissingParentDirectories(file)) { XmUtil.grantPermissionAndCreateToFile(file.getParentFile(), true); } } super.openFile(file_name); if(file_name != null) { File f = new File(file_name); file_ptr = f; if (f.exists()) { XmUtil.grantPermissionAndCreateToFile(f, false, false); } } } @Override protected void writeOut(E event) throws IOException { if(file_ptr == null){ file_ptr = new File(getFile()); } if(!file_ptr.exists()){ super.openFile(getFile()); } super.writeOut(event); } } ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1599: LoggingEvent.getTimeStamp no longer returns milliseconds
by QOS.CH (JIRA) 20 Dec '21

20 Dec '21

logback / LOGBACK-1599 [Open] LoggingEvent.getTimeStamp no longer returns milliseconds ============================== 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-1599 ============================== Issue created ------------------------------ Brett Kail created this issue on 20/Dec/21 11:19 PM Summary: LoggingEvent.getTimeStamp no longer returns milliseconds Issue Type: Bug Affects Versions: 1.3.0-alpha11 Assignee: Logback dev list Components: logback-classic Created: 20/Dec/21 11:19 PM Priority: Major Reporter: Brett Kail Description: As of [commit ce43569b0f|https://github.com/qos-ch/logback/commit/ce43569b0ffcb9430fc71fd…] the {{LoggingEvent.getTimeStamp}} method is returning seconds rather than milliseconds, which breaks our custom layout, which is currently compatible with both SLF4J 1.x and 2.x and used by projects that are using a mix of both. Is it possible to restore the previous {{getTimeStamp}} behavior of returning milliseconds and add a separate {{LoggingEvent.getSeconds}} method? ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1598) please create a 1.2.9 release tag for https://github.com/qos-ch/logback
by QOS.CH (JIRA) 20 Dec '21

20 Dec '21

1 0

[JIRA] (LOGBACK-1591) Possibility of vulnerability - registered as CVE-2021-42550
by QOS.CH (JIRA) 20 Dec '21

20 Dec '21

1 0

[JIRA] (LOGBACK-1567) Upgrade to jansi 2.3.4
by QOS.CH (JIRA) 20 Dec '21

20 Dec '21

1 0

[JIRA] (LOGBACK-1591) Possibility of vulnerability - registered as CVE-2021-42550
by QOS.CH (JIRA) 20 Dec '21

20 Dec '21

1 0

[JIRA] (LOGBACK-1598) please create a 1.2.9 release tag for https://github.com/qos-ch/logback
by QOS.CH (JIRA) 19 Dec '21

19 Dec '21

1 0

[qos-ch/logback]
by Ceki Gülcü 19 Dec '21

19 Dec '21

Branch: refs/tags/v_1.3.0-alpha12-SNAPSHOT Home: https://github.com/qos-ch/logback

1 0

[qos-ch/logback]
by Ceki Gülcü 19 Dec '21

19 Dec '21

Branch: refs/tags/v_1.3.0-alpha11 Home: https://github.com/qos-ch/logback

1 0