January 2021 - logback-dev - mailman3.qos.ch

[JIRA] Updates for LOGBACK-1550: GraalVM native-image problem with AsyncAppender and RollingFileAppender
by QOS.CH (JIRA) 22 Jan '21

22 Jan '21

logback / LOGBACK-1550 [Open] GraalVM native-image problem with AsyncAppender and RollingFileAppender ============================== 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-1550 ============================== Issue created ------------------------------ Azman Kudus created this issue on 22/Jan/21 11:45 AM Summary: GraalVM native-image problem with AsyncAppender and RollingFileAppender Issue Type: Bug Affects Versions: 1.2.3 Assignee: Logback dev list Components: logback-classic Created: 22/Jan/21 11:45 AM Environment: Windows 10 64-bit Visual Studio Build Tools 2019 Micronaut 2.2.3 GraalVM CE 20.3.0 Logback 1.2.3 Priority: Major Reporter: Azman Kudus Description: Hi, I'm getting error while creating native-image with Micronaut and GraalVM. ConsoleAppender only is working fine. But with AsyncAppender and/or RollingFileAppender, the following error appears. There is existing issues discussed in this link [https://github.com/micronaut-projects/micronaut-core/issues/3683] *+logback.xml+* {{<configuration>}} {{ <property name="log.dir" value="log" />}} {{ <property name="line.pattern" value="%d\{yyyy-MM-dd HH:mm:ss.SSS XXX} %-5level %thread %logger\{36} %msg%n" />}} {{ <property name="file.pattern" value="app_%d\{yyyyMMdd_}_%i.log" />}}{{<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">}} {{ <encoder>}} {{ <pattern>${line.pattern}</pattern>}} {{ </encoder>}} {{ </appender>}} {{ <appender name="CONSOLE_ASYNC" class="ch.qos.logback.classic.AsyncAppender">}} {{ <appender-ref ref="CONSOLE" />}} {{ </appender>}}{{<root level="INFO">}} {{ <appender-ref ref="CONSOLE" />}} {{ }} {{ </root>}}{{<logger name="test" level="TRACE" />}} {{</configuration>}} {{}} *+native-image+* {{> native-image --no-server --no-fallback --static --class-path build\libs\test-0.0.1-all.jar test.Main}} {{Warning: Ignoring server-mode native-image argument --no-server.}} {{[test.main:19224] classlist: 2,344.53 ms, 0.96 GB}} {{[test.main:19224] (cap): 4,023.40 ms, 0.96 GB}} {{[test.main:19224] setup: 6,241.80 ms, 0.96 GB}} {{[test.main:19224] (clinit): 1,257.96 ms, 5.20 GB}} {{[test.main:19224] (typeflow): 21,101.03 ms, 5.20 GB}} {{[test.main:19224] (objects): 22,628.06 ms, 5.20 GB}} {{[test.main:19224] (features): 1,918.00 ms, 5.20 GB}} {{[test.main:19224] analysis: 49,171.54 ms, 5.20 GB}} {{Error: Detected a started Thread in the image heap. Threads running in the image generator are no longer running at image runtime. To see how this object got instantiated use --trace-object-instantiation=ch.qos.logback.core.AsyncAppenderBase$Worker. The object was probably created by a class initializer and is reachable from a static field. You can request class initialization at image runtime by using the option --initialize-at-run-time=<class-name>. Or you can write your own initialization methods and call them explicitly from your main entry point.}} {{Detailed message:}} {{Trace: Object was reached by}} {{ reading field java.util.concurrent.locks.AbstractQueuedSynchronizer$Node.thread of}} {{ constant java.util.concurrent.locks.AbstractQueuedSynchronizer$Node@7898fa69 reached by}} {{ reading field java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.firstWaiter of}} {{ constant java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@8eb5f0 reached by}} {{ reading field java.util.concurrent.ArrayBlockingQueue.notEmpty of}} {{ constant java.util.concurrent.ArrayBlockingQueue@487133c7 reached by}} {{ reading field ch.qos.logback.core.AsyncAppenderBase.blockingQueue of}} {{ constant ch.qos.logback.classic.AsyncAppender@658264fb reached by}} {{ reading field ch.qos.logback.core.status.StatusBase.origin of}} {{ constant ch.qos.logback.core.status.InfoStatus@72d5d50d reached by}} {{ indexing into array}} {{ constant java.lang.Object[]@795ec0cf reached by}} {{ reading field java.util.ArrayList.elementData of}} {{ constant java.util.ArrayList@1674196a reached by}} {{ reading field ch.qos.logback.core.BasicStatusManager.statusList of}} {{ constant ch.qos.logback.core.BasicStatusManager@8cc9763 reached by}} {{ reading field ch.qos.logback.core.ContextBase.sm of}} {{ constant ch.qos.logback.classic.LoggerContext@55278968 reached by}} {{ reading field ch.qos.logback.classic.Logger.loggerContext of}} {{ constant ch.qos.logback.classic.Logger@763dead4 reached by}} {{ scanning method io.micronaut.context.DefaultBeanContext.lambda$null$49(DefaultBeanContext.java:2089)}} {{Call path from entry point to io.micronaut.context.DefaultBeanContext.lambda$null$49(BeanType, Optional, Function, BeanType):}} {{ at io.micronaut.context.DefaultBeanContext.lambda$null$49(DefaultBeanContext.java:2068)}} {{ at io.micronaut.context.DefaultBeanContext$$Lambda$720/0x00000007c1532c40.test(Unknown Source)}} {{ at com.oracle.svm.reflect.Predicate_test_d1a7993465a57621e038e1464fe9f954660d921a_577.invoke(Unknown Source)}} {{ at java.lang.reflect.Method.invoke(Method.java:566)}} {{ at java.util.ServiceLoader$ProviderImpl.invokeFactoryMethod(ServiceLoader.java:736)}} {{ at java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:719)}} {{ at com.oracle.svm.core.jdk.SystemPropertiesSupport.initializeLazyValue(SystemPropertiesSupport.java:190)}} {{ at com.oracle.svm.core.jdk.SystemPropertiesSupport.getProperty(SystemPropertiesSupport.java:143)}} {{ at com.oracle.svm.core.jdk.Target_java_lang_System.getProperty(JavaLangSubstitutions.java:330)}} {{ at com.oracle.svm.jni.JNIJavaCallWrappers.jniInvoke_ARRAY:Ljava_lang_System_2_0002egetProperty_00028Ljava_lang_String_2_00029Ljava_lang_String_2(generated:0)}}{{Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception}} {{Error: Image build request failed with exit status 1}} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1549: NPE since classic doesn't open package ".model.processor" for core
by QOS.CH (JIRA) 19 Jan '21

19 Jan '21

logback / LOGBACK-1549 [Open] NPE since classic doesn't open package ".model.processor" for core ============================== 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-1549 ============================== Issue created ------------------------------ Vladislav Fuks created this issue on 19/Jan/21 11:42 AM Summary: NPE since classic doesn't open package ".model.processor" for core Issue Type: Bug Affects Versions: 1.3.0-alpha5 Assignee: Logback dev list Components: logback-classic Created: 19/Jan/21 11:42 AM Environment: jdk: 14 slf4j: 2.0.0-alpha1 logback: 1.3.0-alpha5 modularized application Priority: Major Reporter: Vladislav Fuks Description: There is NPE by initializing of Logger: {code:java} org.slf4j.LoggerFactory.getLogger(getClass()){code} {code:java} java.lang.NullPointerException: Cannot invoke "ch.qos.logback.core.model.processor.ModelHandlerBase.isSupportedModelType(ch.qos.logback.core.model.Model)" because "handler" is nulljava.lang.NullPointerException: Cannot invoke "ch.qos.logback.core.model.processor.ModelHandlerBase.isSupportedModelType(ch.qos.logback.core.model.Model)" because "handler" is null at ch.qos.logback.core/ch.qos.logback.core.model.processor.DefaultProcessor.traverse(DefaultProcessor.java:114) at ch.qos.logback.core/ch.qos.logback.core.model.processor.DefaultProcessor.traversalLoop(DefaultProcessor.java:39) at ch.qos.logback.core/ch.qos.logback.core.model.processor.DefaultProcessor.process(DefaultProcessor.java:54) at ch.qos.logback.core/ch.qos.logback.core.joran.GenericConfigurator.processModel(GenericConfigurator.java:178) at ch.qos.logback.core/ch.qos.logback.core.joran.GenericConfigurator.playEventsAndProcessModel(GenericConfigurator.java:165) at ch.qos.logback.core/ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:151) at ch.qos.logback.core/ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:115) at ch.qos.logback.core/ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:58) at ch.qos.logback.classic/ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:82) at ch.qos.logback.classic/ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:157) at ch.qos.logback.classic/ch.qos.logback.classic.spi.LogbackServiceProvider.initializeLoggerContext(LogbackServiceProvider.java:49) at ch.qos.logback.classic/ch.qos.logback.classic.spi.LogbackServiceProvider.initialize(LogbackServiceProvider.java:40) at org.slf4j/org.slf4j.LoggerFactory.bind(LoggerFactory.java:152) at org.slf4j/org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:139) at org.slf4j/org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:418) at org.slf4j/org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:404) at org.slf4j/org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:353) at org.slf4j/org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:379) {code} It can be fixed with adding to the run configuration: {code:java} --add-opens ch.qos.logback.classic/ch.qos.logback.classic.model.processor=ch.qos.logback.core {code} Should this be defined in the {{module-info}} of the {{ch.qos.logback.classic}}? ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

JDK 16 is now in Rampdown Phase Two
by Rory O'Donnell 15 Jan '21

15 Jan '21

Hi Ceki, *Per the JDK 16 schedule , we are in Rampdown Phase Two* *[1] . * *Please advise if you find any issues while testing the latest Early Access builds.* * Schedule for JDK 16 o *2021/01/14 Rampdown Phase Two* o 2021/02/04 Initial Release Candidate o 2021/02/18 Final Release Candidate o 2021/03/16 General Availability * Release Notes [2] OpenJDK 16 Early Access build 32**is now available at http://jdk.java.net/16 * 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>. * Features [3] - the overall feature set is frozen. No further JEPs will be targeted to this release. * Changes in recent builds that maybe of interest: o Build 32: + JDK-8259028 - ClassCastException when using custom filesystem with wrapper FileChannel impl # Apache Lucene found. + JDK-8253996 - Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing # Apache Zookeeper found. o Build 31: + JDK-8259027: NullPointerException in makeMappedSegment due to NULL Unmapper when length of segment is 0 # Reported by Apache Lucene o Build 30: + JDK-8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation # Reported by JUnit5 + JDK-8256693: getAnnotatedReceiverType parameterizes types too eagerly * JDK 16 - topics of interest o Investigating MD5 overheads: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html o Towards OpenJDK 17 - a quick update on startup performance https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html o Migrating OpenJDK to Git & GitHub - GitHub Universe 2020 session replay https://inside.java/2020/12/11/skara-github-universe/ Project Panama/foreign EA Build 16-panama+3-385 (2020/12/10) <https://jdk.java.net/panama/> is available now [4] * What's new o jextract is now fully compatible with Java 16 o New architecture based on Foreign-Memory Access API (JEP 370 <https://openjdk.java.net/jeps/370>, JEP 383 <https://openjdk.java.net/jeps/383>, JEP 393 <https://openjdk.java.net/jeps/393>) and Foreign Linker API (JEP 389 <https://openjdk.java.net/jeps/389>) * 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> * EA 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 panama-dev(a)openjdk.java.net <panama-dev(a)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>. * Project Panama - topics of interest o “The Vector API” with John Rose and Paul Sandoz https://inside.java/2020/11/17/podcast-007/ o “The Foreign Memory Access API” with Maurizio Cimadamore and Jorn Vernee https://inside.java/2020/12/11/podcast-009/ o “The Foreign Linker API” with Maurizio Cimadamore and Jorn Vernee https://inside.java/2020/12/21/podcast-010/ OpenJDK 17 Early Access build 5**is now available at http://jdk.java.net/17 * 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 recent builds that maybe of interest: o Build 4: + JDK-8258800: Deprecate -XX:+AlwaysLockClassLoader o Build 3: + JDK-8246005: KeyStoreSpi::engineStore(LoadStoreParameter) spec mismatch to its behavior + JDK-8258765: getAnnotatedReceiverType parameterizes types too eagerly * JDK 17 - topic of interest o Towards OpenJDK 17 - a quick update on startup performance: + https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html Java Cryptographic Roadmap [5] has been updated * Removing root certificates with 1024-bit keys in July 2021 CPU. * Disabling of SHA-1 JARS signed after 2019-01-01 has been postponed to July 2021 CPU. Rgds, Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-January/005001.html [2] https://jdk.java.net/16/release-notes [3] http://openjdk.java.net/projects/jdk/16/ <http://openjdk.java.net/projects/jdk/16/> [4] https://mail.openjdk.java.net/pipermail/panama-dev/2020-December/011605.html <https://mail.openjdk.java.net/pipermail/panama-dev/2020-December/011605.html> [5] https://java.com/en/jre-jdk-cryptoroadmap.html <https://java.com/en/jre-jdk-cryptoroadmap.html>

1 0

[JIRA] Updates for LOGBACK-1548: Race condition in the AsyncAppenderBase#Worker thread during shutdown
by QOS.CH (JIRA) 13 Jan '21

13 Jan '21

logback / LOGBACK-1548 [Open] Race condition in the AsyncAppenderBase#Worker thread during shutdown ============================== 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-1548 ============================== Issue created ------------------------------ Dmitry Kaukov created this issue on 13/Jan/21 3:11 AM Summary: Race condition in the AsyncAppenderBase#Worker thread during shutdown Issue Type: Bug Affects Versions: 1.2.3 Assignee: Logback dev list Components: logback-core Created: 13/Jan/21 3:11 AM Labels: AsyncAppender Priority: Major Reporter: Dmitry Kaukov Description: The AsyncAppenderBase#Worker thread may not clear interrupt flag here: [https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch…] (when it exits loop by parent.isStarted() condition). As a result, in our projects it fails to properly flush queue and properly stop appenders. This is what we can see in the logs: {code} 13:06:59,188 |-INFO in ch.qos.logback.classic.AsyncAppender[ASYNC-KAFKA] - Worker thread will flush remaining events before exiting. 13:06:59,189 |-ERROR in com.opentable.logging.KafkaAppender[KAFKA] - Appender [KAFKA] failed to append. org.apache.kafka.common.errors.InterruptException: java.lang.InterruptedException at org.apache.kafka.common.errors.InterruptException: java.lang.InterruptedException at at org.apache.kafka.clients.producer.KafkaProducer.doSend(KafkaProducer.java:967) at at org.apache.kafka.clients.producer.KafkaProducer.send(KafkaProducer.java:865) at at org.apache.kafka.clients.producer.KafkaProducer.send(KafkaProducer.java:752) at at com.opentable.logging.KafkaAppender.append(KafkaAppender.java:82) at at com.opentable.logging.KafkaAppender.append(KafkaAppender.java:32) at at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) at at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) at at ch.qos.logback.core.AsyncAppenderBase$Worker.run(AsyncAppenderBase.java:299) {code} ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for LOGBACK-1547: can custom converter work at global
by QOS.CH (JIRA) 04 Jan '21

04 Jan '21

logback / LOGBACK-1547 [Open] can custom converter work at global ============================== 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-1547 ============================== Issue created ------------------------------ Allen chow created this issue on 04/Jan/21 3:06 PM Summary: can custom converter work at global Issue Type: Improvement Assignee: Logback dev list Components: logback-core Created: 04/Jan/21 3:06 PM Priority: Major Reporter: Allen chow Description: The custom *Converter* can't working when we put a that at end of configuration file. 1. But when we look at configuration file. that *Converter* more like a global component, so should we let that work if it at end of configuration or at begin off the file. 2. Especially when at configuration file include another configuration file, we want to custom *Converter* by the include file, and let it work in our application. but at now we can't make it work. 3. The reason why it not work is the logger pattern is assembling step by step while the configuration file is parsing and not at step of after all configuration file done then assembling the the logger related component. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0