December 2020 - logback-dev

[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

JDK 16 is in Rampdown Phase One
by Rory O'Donnell 13 Dec '20

13 Dec '20

Hi Ceki, *Per the JDK 16 schedule , we are in Rampdown Phase One* *[1] . * *Please advise if you find any issues while testing the latest Early Access builds.* * Schedule for JDK 16 o *2020/12/10 Rampdown Phase One* 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 28**is now available at http://jdk.java.net/16 * Features - the overall feature set is frozen. No further JEPs will be targeted to this release. * Significant Integrations in b28: o *Integrated JEP 396: **Strongly Encapsulate JDK Internals by Default <https://openjdk.java.net/jeps/396>** * + Strongly encapsulate all internal elements of the JDK by default, except for critical internal APIs <https://openjdk.java.net/jeps/260#Description> such as |sun.misc.Unsafe|. + Allow end users to choose the relaxed strong encapsulation that has been the default since JDK 9. o Integrated JEP 397: Sealed Classes (Second Preview) <https://openjdk.java.net/jeps/397> with this release. + Enhance the Java programming language with sealed classes and interfaces <https://cr.openjdk.java.net/~briangoetz/amber/datum.html>. + Refines JEP 360 <https://openjdk.java.net/jeps/360> which was delivered in JDK 15 as a preview feature. * 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 28 + JDK-8256299: JEP 396: Strongly Encapsulate JDK Internals by Default + JDK-8166596: TLS support for the EdDSA signature algorithm + JDK-8256718: Old tracing flags are now obsolete and must be replaced with unified logging o Build 27 + JDK-8159746: (proxy) Support for default methods + JDK-8254631: Better support ALPN byte wire values in SunJSSE Project Loom Early-Access: *Build 16-loom+9-316 <http://jdk.java.net/loom/>* (2020/11/30) - based on JDK-16+25 <https://github.com/openjdk/jdk/releases/tag/jdk-16%2B25> * 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. * 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>. Rgds, Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-December/004991.html [2] https://jdk.java.net/16/release-notes

1 0

[JIRA] Updates for LOGBACK-1544: Problem with program execution with log level WARN an OSGi
by QOS.CH (JIRA) 11 Dec '20

11 Dec '20

logback / LOGBACK-1544 [Open] Problem with program execution with log level WARN an OSGi ============================== 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-1544 ============================== Issue created ------------------------------ Oliver Plohmann created this issue on 11/Dec/20 2:34 PM Summary: Problem with program execution with log level WARN an OSGi Issue Type: Bug Affects Versions: 1.2.3 Assignee: Logback dev list Attachments: logback.xml Components: logback-classic, logback-core Created: 11/Dec/20 2:34 PM Environment: We have a problem with several log statements not showing up in the log during startup of our application when logback is in log level WARN. Problem does not show up for INFO and DEBUG. Problem has showed up recently and disappears when changing <configuration scan="true"> to <configuration>. Interestingly, our logback.xml was defining <configuration scan="true"> all the time (for more than a year) without this problem, also in production. We are using the Felix OSGi container. For the missing log statements not written to the log when in log level WARN there is no problem that the code that issues those log statements were not executed. The whole startup process seems to run correctly without leaving out any startup steps as tons of things that need to be initialized for the application to work at all are carried out correctly. This can be seen from the application working correctly. However, when <configuration scan="true"> is defined rather than <configuration> the application startup fails. The code issuing log entries with level WARN seem not to be executed as the application is not correctly initialized after startup. Log statements in level INFO do not show up in the log. We can trace down the problem to a specific commit in git that first shows this problem. The difference in the code to the commit before, that is working without this problem, shows nothing meaningful. The code changes are all simple and are also not related to logging. Also no changes in setup like different JVM version or anything else like changes in the pom.xml. All changes are on Java code level. Removing the differences and creating another build results in an application jar that still shows the problem. This is a bit weird but confirmed by several pairs of eyes ;). We use the @Slf4j annotation from lombok and do so from the beginning without ever having had the issue described here. The issue is kind of puzzling. With this ticket we are merely kindly asking for some hints where to look for the issue. Our logback.xml files is attached with changed package names not to reveal company internal matters. <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.25</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>1.2.3</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.2.3</version> </dependency> Labels: configuration logging Priority: Minor Reporter: Oliver Plohmann ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

volunteering for bug fix
by Joseph Tsai 07 Dec '20

07 Dec '20

Hi everyone, I am very new to open source contribution and I want to know if I can contribute to this project in any way. Is there a backlog of bugs where I can try my hands on? I have some experience from working as a junior dev, but I don't think I'm growing as fast as I would like to be. Please let me know if I am not using the maillist the way it is intended to be used. Thank you, Joseph

1 0