- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-979) Add documentation how to configure contextListener in Groovy
by QOS.CH (JIRA) 12 Feb '21

12 Feb '21

1 0

JDK 16 is now in the Release Candidate Phase
by Rory O'Donnell 05 Feb '21

05 Feb '21

*Hi Ceki, * *Per the JDK 16 schedule , we are in the Release Candidate Phase**[1] .* *Please advise if you find any issues while testing the latest Early Access builds.* * Schedule for JDK 16 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 35**is now available at http://jdk.java.net/16 <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 34: + JDK-8259025: Record compact constructor using Objects.requireNonNull # Reported by JUnit5 o Build 32: + JDK-8259014: Incomplete support for Unix domain sockets in Windows 2019 Server * JDK 16 - topics of interest: o Unix domain socket channels (JEP-380) overview: https://inside.java/2021/02/03/jep380-unix-domain-sockets-channels/ <https://inside.java/2021/02/03/jep380-unix-domain-sockets-channels/> o Java Feature Spotlight: Pattern Matching https://inside.java/2021/01/22/feature-spotlight-pattern-matching/ <https://inside.java/2021/01/22/feature-spotlight-pattern-matching/> o Foreign Memory Access - Pulling all the thread https://inside.java/2021/01/25/memory-access-pulling-all-the-threads/ <https://inside.java/2021/01/25/memory-access-pulling-all-the-threads/> * General – topic of interest: o Inside Java Episode 11 “How to contribute to OpenJDK” with Stuart Marks and Jesper Wilhelmsson https://inside.java/2021/01/29/podcast-011/ <https://inside.java/2021/01/29/podcast-011/> Project Lanai EA 9 Build 17-lanai+2-49 (2021/1/20) <http://jdk.java.net/lanai/> is available now * 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 intended for developers looking to test and provide feedback on using Project Lanai. * This is a macOS-specific project which implements a new Java 2D graphics rendering pipeline for macOS. * Project Lanai Wiki: https://wiki.openjdk.java.net/display/lanai/Main <https://wiki.openjdk.java.net/display/lanai/Main> * Please send feedback via e-mail to lanai-dev(a)openjdk.java.net <mailto:lanai-dev@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/lanai-dev>. Project Loom Build 17-loom+2-42 (2021/1/14) <http://jdk.java.net/loom/> based on JDK-17+5 <https://github.com/openjdk/jdk/releases/tag/jdk-17%2B5> is available now * 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> * These builds are intended for developers looking to "kick the tyres" and provide feedback on using the API or by sending bug reports. * API Javadoc : https://download.java.net/java/early_access/loom/docs/api/ <https://download.java.net/java/early_access/loom/docs/api/> * Please send feedback via e-mail to loom-dev(a)openjdk.java.net <mailto:loom-dev@openjdk.java.net>. To send e-mail to this address you must first subscribe to the mailing list <http://mail.openjdk.java.net/mailman/listinfo/loom-dev>. OpenJDK 17 Early Access build 8**is now available at http://jdk.java.net/17 <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 8: + JDK-8222850: Misleading cascade compiler error in switch expression with undefined vars # Reported by jOOQ. + JDK-8217633: Configurable extensions with system properties + JDK-8249867: DOM LSSerializer control of newline after XML header + JDK-8256421: Added 2 HARICA Root CA Certificates + JDK-8259801: Enable XML Signature secure validation mode by default o Build 7: + JDK-8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs + JDK-8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension o Build 6: + JDK-8259048: (tz) Upgrade time-zone data to tzdata2020f January 2021 Critical Patch Update Released: * As part of the Jan 2021 CPU we released JDK 15.0.2, JDK 11.0.10 LTS, JDK 8u281, and JDK 7u291 as well as OpenJDK 15.0.2 (publicly available). Rgds, Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-February/005062.html <https://mail.openjdk.java.net/pipermail/jdk-dev/2021-February/005062.html> [2] https://jdk.java.net/16/release-notes <https://jdk.java.net/16/release-notes> [3] http://openjdk.java.net/projects/jdk/16/ <http://openjdk.java.net/projects/jdk/16/> -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[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

[JIRA] Updates for LOGBACK-1546: logback-json-appender.xml: how to customize message pattern
by QOS.CH (JIRA) 31 Dec '20

31 Dec '20

logback / LOGBACK-1546 [Open] logback-json-appender.xml: how to customize message pattern ============================== 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-1546 ============================== Issue created ------------------------------ Nicola Spreafico created this issue on 31/Dec/20 11:08 AM Summary: logback-json-appender.xml: how to customize message pattern Issue Type: Improvement Assignee: Logback dev list Created: 31/Dec/20 11:08 AM Priority: Major Reporter: Nicola Spreafico Description: Hi, I have an App Engine application (java11) with Spring Boot. I configured the logback in order to write console_json logs on Cloud Logging. {code:java} <configuration> <include resource="org/springframework/boot/logging/logback/defaults.xml" /> <include resource="org/springframework/boot/logging/logback/console-appender.xml" /> <springProfile name="development | stage | production"> <include resource="org/springframework/cloud/gcp/logging/logback-json-appender.xml" /> <root level="INFO"> <appender-ref ref="CONSOLE_JSON" /> </root> </springProfile> <springProfile name="localhost"> <root level="INFO"> <appender-ref ref="CONSOLE" /> </root> </springProfile> </configuration> {code} I'm trying to understand how (and if possible...) to configure the message pattern, I'd like to add the class and the line number which generated that specific log. {{}} This is an example of a Java8 App Engine standard application (the first generation of App Engine where the log were directly integrated by the infrastructure): [!https://user-images.githubusercontent.com/12278553/103377053-9bae0400-4ade-11eb-817c-2a366ceab760.png!|https://user-images.githubusercontent.com/12278553/103377053-9bae0400-4ade-11eb-817c-2a366ceab760.png] And this is an example of the log produced by my application with the given configuration: [!https://user-images.githubusercontent.com/12278553/103377156-df087280-4ade-11eb-8d3a-4ec3341a7ebf.png!|https://user-images.githubusercontent.com/12278553/103377156-df087280-4ade-11eb-8d3a-4ec3341a7ebf.png] The log creation itself it's working as expected, but I'm not getting the class/line number. Of course I don't expect to obtain the same behaviour where the class reference is clickable, which integrates the sources and all of that. In my case I'm simply trying to add those 2 pieces of information (as simple text) aside with the actual log message. Also, if you notice from the first screenshot, in addition to class simple name and line number at the end, there is also at the beginning the fully qualified name of the class and the method name. Is it something that is achievable at all? I tried playing with the {{<pattern>}} node of the xml but no luck, maybe I need to create a customLayout class or something, can you help me? That data would be very helpful to me as I can directly open the sources pointing to the specific line which generated the log and start from there for debugging. I think that it's something related to {{JsonLayout}} and the possibility to customize the message in order to add the caller information. Thanks ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1545) Caused by: java.lang.NoSuchMethodError: 'void ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty()'
by QOS.CH (JIRA) 28 Dec '20

28 Dec '20

1 0

[JIRA] Updates for LOGBACK-1545: Caused by: java.lang.NoSuchMethodError: 'void ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty()'
by QOS.CH (JIRA) 28 Dec '20

28 Dec '20

logback / LOGBACK-1545 [Open] Caused by: java.lang.NoSuchMethodError: 'void ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty()' ============================== 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-1545 ============================== Issue created ------------------------------ guiji created this issue on 28/Dec/20 3:16 AM Summary: Caused by: java.lang.NoSuchMethodError: 'void ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty()' Issue Type: Bug Assignee: Logback dev list Created: 28/Dec/20 3:16 AM Priority: Major Reporter: guiji Description: Caused by: java.lang.NoSuchMethodError: 'void ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty()' at ch.qos.logback.classic.joran.action.ConfigurationAction.begin(ConfigurationAction.java:57) at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:269) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:145) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:128) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:165) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:152) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:110) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53) at org.springframework.boot.logging.logback.LogbackLoggingSystem.configureByResourceUrl(LogbackLoggingSystem.java:176) at org.springframework.boot.logging.logback.LogbackLoggingSystem.loadConfiguration(LogbackLoggingSystem.java:153) at org.springframework.boot.logging.logback.LogbackLoggingSystem.reinitialize(LogbackLoggingSystem.java:220) at org.springframework.boot.logging.AbstractLoggingSystem.initializeWithConventions(AbstractLoggingSystem.java:73) at org.springframework.boot.logging.AbstractLoggingSystem.initialize(AbstractLoggingSystem.java:60) at org.springframework.boot.logging.logback.LogbackLoggingSystem.initialize(LogbackLoggingSystem.java:118) at org.springframework.boot.context.logging.LoggingApplicationListener.initializeSystem(LoggingApplicationListener.java:289) at org.springframework.boot.context.logging.LoggingApplicationListener.initialize(LoggingApplicationListener.java:264) at org.springframework.boot.context.logging.LoggingApplicationListener.onApplicationEnvironmentPreparedEvent(LoggingApplicationListener.java:226) at org.springframework.boot.context.logging.LoggingApplicationListener.onApplicationEvent(LoggingApplicationListener.java:203) at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172) at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:127) at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:76) at org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:53) at org.springframework.boot.SpringApplication.prepareEnvironment(SpringApplication.java:342) at org.springframework.boot.SpringApplication.run(SpringApplication.java:305) at org.springframework.boot.builder.SpringApplicationBuilder.run(SpringApplicationBuilder.java:140) at org.springframework.cloud.bootstrap.BootstrapApplicationListener.bootstrapServiceContext(BootstrapApplicationListener.java:203) at org.springframework.cloud.bootstrap.BootstrapApplicationListener.onApplicationEvent(BootstrapApplicationListener.java:114) at org.springframework.cloud.bootstrap.BootstrapApplicationListener.onApplicationEvent(BootstrapApplicationListener.java:71) at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172) at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:127) at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:76) at org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:53) at org.springframework.boot.SpringApplication.prepareEnvironment(SpringApplication.java:342) at org.springframework.boot.SpringApplication.run(SpringApplication.java:305) at org.springframework.boot.web.servlet.support.SpringBootServletInitializer.run(SpringBootServletInitializer.java:151) at org.springframework.boot.web.servlet.support.SpringBootServletInitializer.createRootApplicationContext(SpringBootServletInitializer.java:131) at org.springframework.boot.web.servlet.support.SpringBootServletInitializer.onStartup(SpringBootServletInitializer.java:91) at org.springframework.web.SpringServletContainerInitializer.onStartup(SpringServletContainerInitializer.java:172) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5152) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) ... 10 more ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0