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

Allow context configuration through Java class

    XMLWordPrintable

Details

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 1.0.7
    • logback-classic
    • None

    Description

      Currently, initialization of a Logback context is handled by ch.qos.logback.classic.util.ContextInitializer.autoConfig(). This is documented at http://logback.qos.ch/manual/configuration.html#auto_configuration , and is pretty much summarized as try to configure through a configuration file (Groovy or XML), otherwise fall back to the BasicConfigurator. (The documentation doesn't currently account for findConfigFileURLFromSystemProperties.)

      I have repeatedly run into a need to provide a more advanced configuration, especially for use across several JEE web applications. Groovy is a good choice for this - and would actually allow for calls back into regular Java code, but it requires including additional dependencies (for Groovy) that I'd rather typically avoid.

      It would be good to have the option to handle the configuration through a Java class (if it exists) - which could optionally chain back to the the findURLOfDefaultConfigurationFile and configureByResource methods of ContextInitializer. This is mostly possible through the approach documented at http://logback.qos.ch/manual/configuration.html#joranDirectly . However: 1) There is not a great way to execute such code "on-demand" when the context is first initialized (as is currently done with the configuration files), and 2) the context will already have been configured once (through ContextInitializer.autoConfig()) by this point, requiring redundant work. (I don't see a way to avoid this, as the context is initialized upon calling LoggerFactory.getILoggerFactory() - which I believe is necessary to obtain the context to configure.)

      Following the spirit of the org.slf4j.impl.StaticLoggerBinder, I propose that something like a ch.qos.logback.classic.ConfigurationBinder class could be provided as a "first opportunity" configuration provider. If it doesn't exist on the classpath, configuration would proceed as it does currently. However, if it does exist, it could be somehow called in place of everything beyond the 1st line of the current autoConfig() method. Invocation could either be a specifically-named static method, or simply a default class constructor, or maybe the best option - perform default instantiation on the class, and call an interface method (requiring this class to implement a Logback interface).

      If consensus can be reached that this would be a good idea, I can work on providing a contribution to implement this - but would just like to first ensure that it would have a good chance of being accepted into the project.

      Thanks!

      Attachments

        Activity

          People

            logback-dev Logback dev list
            ziesemer Mark A. Ziesemer
            Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: