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

Add ability to manually specify configuration BEFORE autoconfiguration

    XMLWordPrintable

Details

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • 0.9.29
    • None
    • None

    Description

      In order to make logback initialization faster, I would like the ability to programmatically configure logback and avoid the logic that happens in ContextInitializer.autoConfig().

      Specifically, refer to this stack that occurs when getILoggerFactory() is initially called...

      ch.qos.logback.classic.util.ContextInitializer.autoConfig() line: 147
      org.slf4j.impl.StaticLoggerBinder.init() line: 85
      org.slf4j.impl.StaticLoggerBinder.<clinit>() line: 55
      org.slf4j.LoggerFactory.bind() line: 121
      org.slf4j.LoggerFactory.performInitialization() line: 111
      org.slf4j.LoggerFactory.getILoggerFactory() line: 268

      Now, for some background...

      I am using logback for a fast executing CLI program. Right now, initializing logback dominates the execution time of my CLIs. For example...

      When I started with logback, I was using logback.xml. If one of my CLIs took 1.5 seconds to run, I would see that initializing logback was taking 1 of those seconds (I used the yourkit profiler to identify this). 66% of the execution time is unacceptable.

      So, I switched from using logback.xml to programatically configuring logback in Java with the following code..

          LoggerContext loggingContext = (LoggerContext) LoggerFactory.getILoggerFactory();
      
          loggingContext.reset();
          ...
          FileAppender<ILoggingEvent> fileAppender = new FileAppender<ILoggingEvent>();
          ...
          Logger rootLogger = loggingContext.getLogger(Logger.ROOT_LOGGER_NAME);
          rootLogger.addAppender(fileAppender);
      

      This reduced the initialization time quite a bit. Now logback initialization is taking about .3 seconds. This is much better.

      However, I still think this can be improved by completely skipping the auto config logic.

      The initial call to LoggerFactory.getILoggerFactory() will attempt to auto configure logback.... which searches for groovy files, xml files, and falls back to BasicConfigurator. I don't need this auto configuration logic, since I am just going reset it and configure it myself anyway.

      I would like the ability to programmatically configure logback and totally avoid this auto configuration.

      Ideally I would be able to construct a LoggerContext instance, or the root Logger, or something. Then allow slf4j to bind to it without going through the auto config steps.

      Attachments

        Activity

          People

            logback-dev Logback dev list
            philsttr Phil
            Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: