June 2017 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1310) TimeBasedRollingPolicy property totalSizeCap perform bad
by QOS.CH (JIRA) 07 Jun '17

07 Jun '17

finalmachine created LOGBACK-1310: ------------------------------------- Summary: TimeBasedRollingPolicy property totalSizeCap perform bad Key: LOGBACK-1310 URL: https://jira.qos.ch/browse/LOGBACK-1310 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.2.3 Environment: windows 7 x64 Java 8u131 Reporter: finalmachine Assignee: Logback dev list Attachments: pic1.PNG I use this appender <{color:#000080}appender {color}{color:#0000ff}name{color}{color:#008000}="test" {color}{color:#0000ff}class{color}{color:#008000}="ch.qos.logback.core.rolling.RollingFileAppender">{color} <{color:#000080}prudent{color}>true</{color:#000080}prudent{color}> <{color:#000080}rollingPolicy {color}{color:#0000ff}class{color}{color:#008000}="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"{color}> <{color:#000080}fileNamePattern{color}>./logs/free-%d\{yyyy-MM-dd}.log</{color:#000080}fileNamePattern{color}> <{color:#000080}cleanHistoryOnStart{color}>true</{color:#000080}cleanHistoryOnStart{color}> <{color:#000080}maxHistory{color}>30</{color:#000080}maxHistory{color}> <{color:#000080}totalSizeCap{color}>70MB</{color:#000080}totalSizeCap{color}> </{color:#000080}rollingPolicy{color}> <{color:#000080}encoder{color}> <{color:#000080}pattern{color}>%d\{yyyy-MM-dd HH:mm:ss} [%thread] (%level) %C(%F:%L) %n%msg%n</{color:#000080}pattern{color}> </{color:#000080}encoder{color}> </{color:#000080}appender{color}> then I write a test java code {color:#333333}public static void main(String[] args) \{{color} {color:#333333} Logger logger = LoggerFactory.getLogger("test");{color} {color:#333333} for (int i = 0; i < 1000000; i++) \{{color} {color:#333333} logger.info(UUID.randomUUID().toString());{color} {color:#333333} }{color} } I run the program first time,It give me a logger file 114MB,it is very sad because the size is great than 70MB as conf file. {color:#333333}in the [https://logback.qos.ch/manual/appenders.html] you say the "total size cap" restriction applied second.{color} so I delete some log to make the log file size 12MB, and I rename the file name as it is created yesteday, then I run the java program again, when total size great than 70MB, the old log file is not delete, and the result is in Attachment pic1.PNG. I‘d like discuss the requrement of {color:#008000}TimeBasedRollingPolicy{color}, I use it to split log by day, at the same time prevent the total log file great than the disk size or the server will wrong, so I need logback to hold all files which macthes {color:#000080}fileNamePattern{color} within disk size. now I just use SizeAndTimeBasedRollingPolicy, but I dislike the %i. So maybe this bug is more like a new feather, Hope logback do better. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-995) Standalone rollover gets exception
by QOS.CH (JIRA) 05 Jun '17

05 Jun '17

1 0

[JIRA] (LOGBACK-1309) No autoscaning for changed logback.xml when using http-URI for config file
by QOS.CH (JIRA) 04 Jun '17

04 Jun '17

Jørgen Ringen created LOGBACK-1309: -------------------------------------- Summary: No autoscaning for changed logback.xml when using http-URI for config file Key: LOGBACK-1309 URL: https://jira.qos.ch/browse/LOGBACK-1309 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.1.11 Environment: MacOS, Spring Boot 1.5.3.RELEASE, Java 8 Reporter: Jørgen Ringen Assignee: Logback dev list Here is my logback.xml: {code:java} <configuration scan="true" scanPeriod="10 seconds"> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern> %d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n </pattern> </encoder> </appender> <logger name="com.acme" level="DEBUG" additivity="false"> <appender-ref ref="STDOUT"/> </logger> <root level="INFO"> <appender-ref ref="STDOUT"/> </root> </configuration>{code} Notice that scan=true and scanPeriod=10 seconds. I host my logback.xml file on a remote server and I use Spring Boot to instantiate logback. Spring boot takes the property -Dlogging.config=[http://acme.com:1337/logback.xml] and passes this to: ch.qos.logback.core.joran.GenericConfigurator#doConfigure(java.net.URL) Logback looks up the config-file from the remote url, instantiates the config, and everything seems fine, except for autoscanning. I see that logback uses the class ch.qos.logback.core.joran.spi.ConfigurationWatchList to keep track of files with autoscanning and a class called ch.qos.logback.classic.joran.ReconfigureOnChangeTask to do the periodic polling. When a URI is added to the watch-list, the following code is executed: {code:java} ch.qos.logback.core.joran.spi.ConfigurationWatchList#addAsFileToWatch private void addAsFileToWatch(URL url) { File file = convertToFile(url); if (file != null) { fileWatchList.add(file); lastModifiedList.add(file.lastModified()); } } ch.qos.logback.core.joran.spi.ConfigurationWatchList#convertToFile File convertToFile(URL url) { String protocol = url.getProtocol(); if ("file".equals(protocol)) { return new File(URLDecoder.decode(url.getFile())); } else { addInfo("URL [" + url + "] is not of type file"); return null; } } {code} Notice that theres a check to ensure that the URL-protocol is "file". This check fails for URL's with http-protocol, so no autoscanning is performed on the configuration-file. Is this expected behaviour? If so, why, and is it possible to create a feature-request for autoscanning on http-uri's? -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1305) Logback-classic cannot be built by Eclipse m2e due to importing default package
by QOS.CH (JIRA) 02 Jun '17

02 Jun '17

1 0

[JIRA] (LOGBACK-1308) Allow LoggerContext subclasses to update newly-created Loggers
by QOS.CH (JIRA) 02 Jun '17

02 Jun '17

Richard Sand created LOGBACK-1308: ------------------------------------- Summary: Allow LoggerContext subclasses to update newly-created Loggers Key: LOGBACK-1308 URL: https://jira.qos.ch/browse/LOGBACK-1308 Project: logback Issue Type: Improvement Components: logback-classic Affects Versions: 1.3.0, 1.2.4 Environment: all Reporter: Richard Sand Assignee: Logback dev list Attachments: LoggerContext.patch I've a use case where I am adapting Logback with a legacy product's proprietary log mechanism. I did this by creating a wrapper class around a Logger, creating custom appenders which wrap the product's logging API, and directly attaching the appenders necessary according to the product's configuration settings. Now I am trying to enable 3rd-party plugins, which are written for this product, to be able to directly use Logger.getLogger() to log, and not have to even worry about the product's proprietary (and clunky) logging API. But this proves difficult in Logback, because there is no hook to programmatically touch the Logger instances at creation-time. A custom LoggerContext doesn't help because the getLogger() method is final, and the Logger class itself is also final, allowing no extensibility. The patch I have supplied provides this hook by simply adding a method in LoggerContext that is invoked directly after Logger.createChildByName(), which by default is a no-op but can be overridden by custom contexts. {{ /**}} {{ * Allows subclasses to perform post-create modifications on newly-created \{@link Logger} instances.}} {{ * By default, this method does nothing}} {{ * }} {{ * @param childLogger}} {{ */}} {{ protected void customizeNewLogger(final Logger childLogger) \{}} {{ }}} Inside the getLogger() method, this is invoked directly after creation: {{ childLogger = logger.getChildByName(childName);}} {{ if (childLogger == null) \{}} {{ childLogger = logger.createChildByName(childName);}} {{{color:#d04437} customizeNewLogger(childLogger);{color}}} {{ loggerCache.put(childName, childLogger);}} {{ incSize();}} {{ }}} Thanks for your consideration of this update! -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Announcing: Early-Access builds of JDK 9 for Alpine Linux/musl at jdk.java.net/9/
by Rory O'Donnell 02 Jun '17

02 Jun '17

Hi Ceki, ** *Announcing: Early-Access builds of JDK 9 for Alpine Linux/musl at jdk.java.net/9/ [1] * * As of today there are pre-built Early-Access (EA) JDK binaries for Alpine Linux/musl at jdk.java.net/9/** o look for “Alpine Linux”. [1] * The Alpine Linux build is compatible with linux distributions that use the musl C library. *[2]* Feedback is very welcome via the portola-dev mailing list, remembering to subscribe to the mailing list first. *Proposed schedule change for JDK 9 [3]* JDK 9 Project continues to work toward the current goal of producing an initial Release Candidate build on 22 June. This proposal is to adjust the GA date in order to accommodate the additional time required to move through the JCP process. To be specific, we propose to move the GA date out by eight weeks, from 27 July to 21 September. Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/portola-dev/2017-June/000191.html [2] http://www.musl-libc.org/ [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0