I've a use case where I am adapting Logback with a legacy product's proprietary log mechanism. I did this by creating a wrapper class around a Logger, creating custom appenders which wrap the product's logging API, and directly attaching the appenders necessary according to the product's configuration settings.

Now I am trying to enable 3rd-party plugins, which are written for this product, to be able to directly use Logger.getLogger() to log, and not have to even worry about the product's proprietary (and clunky) logging API. But this proves difficult in Logback, because there is no hook to programmatically touch the Logger instances at creation-time. A custom LoggerContext doesn't help because the getLogger() method is final, and the Logger class itself is also final, allowing no extensibility.

The patch I have supplied provides this hook by simply adding a method in LoggerContext that is invoked directly after Logger.createChildByName(), which by default is a no-op but can be overridden by custom contexts.

 /**
  * Allows subclasses to perform post-create modifications on newly-created {@link Logger} instances.
  * By default, this method does nothing
  *  
  * @param childLogger
  */
{{  protected void customizeNewLogger(final Logger childLogger) {}}
{{  }}}

Inside the getLogger() method, this is invoked directly after creation:

    childLogger = logger.getChildByName(childName);
    if (childLogger == null) {
         childLogger = logger.createChildByName(childName);
         customizeNewLogger(childLogger);
         loggerCache.put(childName, childLogger);
         incSize();
    }

Now inside my custom Context, I can ensure with just a few lines of code that the custom Appender which bridges the legacy product's logging API is automatically included in every Logger instance.

Thanks for your consideration of this update!