Uploaded image for project: 'logback'
  1. logback
  2. LOGBACK-1544

Problem with program execution with log level WARN an OSGi

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.2.3
    • Fix Version/s: None
    • Environment:

      Description

      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>

        Attachments

          Activity

            People

            Assignee:
            logback-dev Logback dev list
            Reporter:
            oliver Oliver Plohmann
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated: