July 2019 - logback-dev - mailman3.qos.ch

Investigation on the diffusion of innovation along with java releases
by Fernando Petrulio 31 Jul '19

31 Jul '19

Dear Developers, we are members of the ZEST research group (Zurich Empirical Software Engineering Team) based at the University of Zurich and the Delft University of Technology. We are conducting an investigation on the diffusion of innovations and we focus on the adoption of new language features. Our research is focused on how API producers adapt their interfaces to introduce support for Java 8’s lambdas. During the course of our investigation, we manually inspected logback-classic and logback-core’s source code and documentation to understand whether Java’s lambdas have widespread adoption. We would like to have your feedback on our findings. Our study focuses primarily on Functional Interfaces and Lambda Expressions as these new features were introduced by the Java language and adopted the Java JDK API, as they reduce implementation complexity, improve readability, offer performance benefits and improve security contextualization. Our analysis showed that LogBack 1.3 did not introduce compatibility with Java 8+ features, including Functional Interfaces and Lambda Expression. We would like to better understand as to why the API does not support newer Java language versions and their features. Our investigation showed us that in most cases API producers do not migrate their APIs to newer Java Releases. Despite this, the API remains to be widely used by consumers on GitHub. Can you provide us with more information on this phenomenon? Did you and your team ever discuss the migration to new Java releases? If so, what did this discussion entail? What is the reason behind not migrating to a newer Java version? Did the introduction of new language features such as lambda expressions influence your decision in any way? Does your API plan on introducing support for lambda expressions in the future? We thank you for taking the time to answer our questions. If you would like to be posted about the results of this study, please let us know! Kind Regards, Fernando Petrulio. -- Fernando Petrulio Ph.D. Student - University of Zurich UZH Department of Informatics fpetrulio(a)ifi.uzh.ch

1 0

[JIRA] (LOGBACK-262) PatternLayout does not really respect ISO8601 for date time
by QOS.CH (JIRA) 30 Jul '19

30 Jul '19

1 0

[JIRA] (LOGBACK-1303) Wrong delimiter in pattern layout for ISO 8601
by QOS.CH (JIRA) 30 Jul '19

30 Jul '19

1 0

[JIRA] (LOGBACK-1477) LoggerContext.putProperty("application-name", "applicationName"); Application name policy implementation, invalid after logback.xml change
by QOS.CH (JIRA) 27 Jul '19

27 Jul '19

1 0

[JIRA] (LOGBACK-1477) LoggerContext.putProperty("application-name", "applicationName"); Application name policy implementation, invalid after logback.xml change
by QOS.CH (JIRA) 26 Jul '19

26 Jul '19

1 0

[JIRA] (LOGBACK-1477) LoggerContext.putProperty("application-name", "applicationName"); Application name policy implementation, invalid after logback.xml change
by QOS.CH (JIRA) 26 Jul '19

26 Jul '19

zhang created LOGBACK-1477: ------------------------------ Summary: LoggerContext.putProperty("application-name", "applicationName");Application name policy implementation, invalid after logback.xml change Key: LOGBACK-1477 URL: https://jira.qos.ch/browse/LOGBACK-1477 Project: logback Issue Type: Bug Affects Versions: 1.2.3 Environment: package test; import java.io.File; import org.slf4j.ILoggerFactory; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import ch.qos.logback.classic.LoggerContext; import ch.qos.logback.classic.joran.JoranConfigurator; public final class Test \{ public final static Logger log = LoggerFactory.getLogger(Test.class); public static void main(String[] args) throws Exception \{ log.error("ZZZZZZZZZZZZZZZZZZZZZZZZZ"); ILoggerFactory loggerFactory = LoggerFactory.getILoggerFactory(); LoggerContext lc = (LoggerContext) loggerFactory; JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); lc.reset(); final File file = new File("./config/logback.xml"); lc.putProperty({color:#ff0000}"application-name"{color}, "applicationName"); configurator.doConfigure(file.getAbsolutePath()); while (true) \{ log.info("YY"); Thread.sleep(5000); System.err.println("X"); } } } <?xml version="1.0" encoding="UTF-8"?> <configuration debug="false" scan="true" nolog="true" scanPeriod="60 seconds"> <property name="logging_home" value="logs/{color:#ff0000}$\{application-name}{color}" /> <property name="logging_backup_home" value="$\{logging_home}/backup" /> <appender name="fileInfoLog" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>$\{logging_home}/logging-info.log</file> <filter class="ch.qos.logback.classic.filter.LevelFilter"> <level>ERROR</level> <onMatch>DENY</onMatch> <onMismatch>ACCEPT</onMismatch> </filter> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <FileNamePattern> $\{logging_backup_home}/%d\{yyyy-MM-dd}/logging-info.%d\{yyyyMMdd}.%i.log.zip </FileNamePattern> <maxHistory>30</maxHistory> <maxFileSize>128MB</maxFileSize> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern> %d\{yyyy-MM-dd HH:mm:ss.SSS} [%thread] [%-5level] [%logger:%line] - %msg%n </pattern> </layout> </appender> <root level="DEBUG"> <appender-ref ref="fileInfoLog" /> </root> </configuration> Reporter: zhang Assignee: Logback dev list Attachments: logback.xml, Test.java, XXXXXXXXXXX.png The application starts the specified name or process name, ouput loggings to directory->applicationName,then adjusts the logback.xml level="DEBUG" to level="INFO" during the running process, the application name policy implementation is invalid, the loggings output change to directory->application-name_IS_UNDEFINED. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1476) Avoid synchronized blocks when copying MDC to a function-local map
by QOS.CH (JIRA) 24 Jul '19

24 Jul '19

Daniel Knittl-Frank created LOGBACK-1476: -------------------------------------------- Summary: Avoid synchronized blocks when copying MDC to a function-local map Key: LOGBACK-1476 URL: https://jira.qos.ch/browse/LOGBACK-1476 Project: logback Issue Type: Improvement Reporter: Daniel Knittl-Frank Assignee: Logback dev list When setting or duplicating the MDC context map, a synchronized map is used. This incurs the overhead of locking when putting key-value pairs into the map. This overhead can be avoided, because the map is method-local and only a single thread can access it a single time. Delay wrapping the map in a synchronizedMap until before it leaves the scope of the method. You can find the proposed changes in [https://github.com/qos-ch/logback/pull/462|https://github.com/qos-ch/logbac…] I have not performed any benchmarks and would appreciate if somebody could write some. Maybe the JVM is already clever enough to detect this useless synchronization and elides the lock? -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 13 enters Rampdown Phase Two
by Rory O'Donnell 22 Jul '19

22 Jul '19

Hi Ceki, Any issues to report on JDK 13 , would like to hear the status as we are now in rampdown phase 2 ? **OpenJDK builds *- JDK 13 Early Access build 30 **is now available **at : - jdk.java.net/13/* * Per the JDK 13 schedule [1], we are now in Rampdown Phase Two. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. o Per the JDK Release Process [3] we now turn our focus to P1 and P2 bugs. * I want to draw your attention to some noteable changes in previous builds of JDK 13. These changes are important for those that develop/maintain their own socket implementation (java.net.SocketImpl) or use the setSocketImplFactory or setSocketFactory APIs to change the system-wide socket implementation: o http://jdk.java.net/13/release-notes#JDK-8224477 - delivered in build 23 o http://jdk.java.net/13/release-notes#JDK-8216978 - delivered in build 20 o http://jdk.java.net/13/release-notes#JDK-8220493 - delivered in build 13 **OpenJDK builds *- JDK 14 Early Access build 6 is **now available **at : - jdk.java.net/14/* * These early-access, open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes of interest since last email o 8225239: Refactor NetworkInterface lookups o 8226409: Enable argument profiling for sun.misc.Unsafe.put*/get* * JEP targeted to JDK 14: o JEP352: Non-Volatile Mapped * Bug fixes reported by Open Source Projects : o JDK-8227080 - fixed in b5 -reported by Eclipse Jetty The Java Crypto Roadmap <https://www.java.com/en/jre-jdk-cryptoroadmap.html> has been updated : * Released - 16-July-2019 - Release Affected JDK 7u231 - Disabled Kerberos DES encryption by default * Targeted Date - 2020 - Targeted Release - JDK 8 - Transport Layer Security (TLS) 1.3 Rgds,Rory [1] http://openjdk.java.net/projects/jdk/13/#Schedule [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-July/003170.html -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (LOGBACK-546) Please add a sequence number to LoggingEvent
by QOS.CH (JIRA) 10 Jul '19

10 Jul '19

1 0

JDK 13 , JDK 14 & Valhalla Early Access builds are available.
by Rory O'Donnell 08 Jul '19

08 Jul '19

Hi Ceki, **OpenJDK* 13 Early Access build **28 is now available **at : - jdk.java.net/13/* * These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes in this build 28 [1] *Reminder of a change in b24 - A jrt URI can only encode paths to files in /modules tree **(JDK-8224946 <https://bugs.openjdk.java.net/browse/JDK-8224946>)* A |jrt| URL is a hierarchical URI with syntax |jrt:/[$MODULE[/$PATH]]|. When using the |jrt| file system, a |java.net.URI| object can be created with the |java.nio.file.Path::toUri| method to encode a normalized path to a file in the |/modules| tree. A |jrt| URL cannot encode a path to a file in the |/packages| tree. The |jrt| file system provider has changed in this release so that |toUri| fails with |IOError| when it is not possible to encode the file path as a jrt URI. *This change may impact tools have been making use of URLs that are not compliant with the syntax. Tools with paths to files in **|/packages|**can use the **|toRealPath()|**method to obtain the real path (in **|/modules|**) before attempting to convert the file path to a URI.* *OpenJDK 14 **Early Access build 4 **is now available **at : - jdk.java.net/14/* * These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes in this build [2] *Project Valhalla "L-World Inline Types" Early-Access Builds* * Build jdk-14-valhalla+1-8 * These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Please send feedback via e-mail to valhalla-dev(a)openjdk.java.net <mailto:valhalla-dev@openjdk.java.net>. To send e-mail to this address you must first subscribe to the mailing list. *The Skara tooling is now open source *[3] we are happy to announce that the tooling for project Skara is now open source and available at * https://github.com/openjdk/skara <https://github.com/openjdk/skara.> The Skara tooling includes both server-side tools (so called "bots") as well as several command-line tools ** If you have any questions, feedback etc. send them to Skara mailing list [4] Rgds, Rory [1] JDK 13 - Changes in b28 here <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B27%22%3A%3…> [2] JDK 14 - Changes in b4 here <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B3%22%3A%3A…> [3] https://mail.openjdk.java.net/pipermail/skara-dev/2019-June/000047.html [4] https://mail.openjdk.java.net/mailman/listinfo/skara-dev -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0