[logback-dev] [JIRA] Updates for LOGBACK-1544: Problem with program execution with log level WARN an OSGi
QOS.CH (JIRA)
noreply-jira at qos.ch
Fri Dec 11 14:48:00 CET 2020
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)
More information about the logback-dev
mailing list