如何低代价将自定义Log4j2包装器绑定到SLF4J？求更优方案

Great question! Your initial idea of modifying the official log4j-slf4j-impl jar works, but it forces you to maintain a custom fork of the binding library—this gets messy when Log4j2 releases updates, as you’ll have to reapply changes every time. Let’s cover two cleaner, lower-maintenance alternatives that leverage extension points built into SLF4J and Log4j2.

Option 1: Extend Log4j2’s LoggerContext (Recommended) #

This approach reuses the official log4j-slf4j-impl binding entirely, so you don’t have to rewrite any SLF4J adapter code. Instead, you hook into Log4j2’s logger creation process to return your custom logger.

Steps: #

1. Create your custom Log4j2 Logger
   As you planned, extend Log4j2’s org.apache.logging.log4j.Logger and override methods like info() to route logs to appenders based on object type.

   public class CustomLog4jLogger extends org.apache.logging.log4j.Logger {
       // Constructor matching Log4j2's Logger implementation
       protected CustomLog4jLogger(LoggerContext context, String name) {
           super(context, name);
       }
   
       @Override
       public void info(Object message) {
           // Your logic to check message type and route to specific appenders
           if (message instanceof MyCustomType) {
               getContext().getConfiguration().getAppender("CustomTypeAppender").append(...);
           } else {
               super.info(message);
           }
       }
   
       // Override other log methods (debug, warn, etc.) as needed
   }
   

2. Extend Log4j2’s LoggerContext
   Override the getLogger() method to return your custom logger instead of the default one:

   public class CustomLoggerContext extends LoggerContext {
       public CustomLoggerContext(String name) {
           super(name);
       }
   
       @Override
       public org.apache.logging.log4j.Logger getLogger(String name) {
           // Return your custom logger instance
           return new CustomLog4jLogger(this, name);
       }
   }
   

3. Register your custom LoggerContext
   Create a factory class that implements Log4j2’s LoggerContextFactory:

   public class CustomLoggerContextFactory implements LoggerContextFactory {
       @Override
       public LoggerContext getContext(String fqcn, ClassLoader loader, boolean currentContext) {
           return new CustomLoggerContext("CustomContext");
       }
   
       // Implement other required methods from LoggerContextFactory
       @Override
       public LoggerContext getContext(String fqcn, ClassLoader loader, boolean currentContext, URI configLocation) {
           return getContext(fqcn, loader, currentContext);
       }
   
       @Override
       public void removeContext(LoggerContext context) {
           // Cleanup logic if needed
       }
   }
   

4. Configure Log4j2 to use your factory
   Add this system property when starting your app:

   -Dlog4j2.loggerContextFactory=com.yourpackage.CustomLoggerContextFactory
   

   Or specify it in your log4j2.xml configuration:

   <Configuration loggerContextFactory="com.yourpackage.CustomLoggerContextFactory">
       <!-- Your appender and logger configs here -->
   </Configuration>
   

Now, when SLF4J’s log4j-slf4j-impl binding requests a logger from Log4j2, it will get your custom instance automatically.

Option 2: Implement a Custom SLF4J Binding #

If you need full control over the SLF4J adapter layer, you can create your own binding instead of modifying the official one. This involves implementing SLF4J’s core interfaces.

Steps: #

1. Implement SLF4J’s Logger interface
   Create an adapter class that wraps your custom Log4j2 logger and delegates all SLF4J method calls to it:

   public class CustomSlf4jLogger implements org.slf4j.Logger {
       private final CustomLog4jLogger log4jLogger;
   
       public CustomSlf4jLogger(CustomLog4jLogger log4jLogger) {
           this.log4jLogger = log4jLogger;
       }
   
       @Override
       public String getName() {
           return log4jLogger.getName();
       }
   
       @Override
       public boolean isInfoEnabled() {
           return log4jLogger.isInfoEnabled();
       }
   
       @Override
       public void info(Object message) {
           log4jLogger.info(message);
       }
   
       // Implement all other SLF4J Logger methods (trace, debug, warn, etc.)
   }
   

2. Implement SLF4J’s ILoggerFactory
   This factory creates instances of your CustomSlf4jLogger:

   public class CustomSlf4jLoggerFactory implements ILoggerFactory {
       private final LoggerContext log4jContext = LogManager.getContext(false);
   
       @Override
       public org.slf4j.Logger getLogger(String name) {
           CustomLog4jLogger customLog4jLogger = (CustomLog4jLogger) log4jContext.getLogger(name);
           return new CustomSlf4jLogger(customLog4jLogger);
       }
   }
   

3. Create SLF4J’s required StaticLoggerBinder
   SLF4J uses this class to discover your binding. Place it in the org.slf4j.impl package:

   public class StaticLoggerBinder implements LoggerFactoryBinder {
       private static final StaticLoggerBinder SINGLETON = new StaticLoggerBinder();
       private final ILoggerFactory loggerFactory = new CustomSlf4jLoggerFactory();
       private final String loggerFactoryClassStr = CustomSlf4jLoggerFactory.class.getName();
   
       public static StaticLoggerBinder getSingleton() {
           return SINGLETON;
       }
   
       @Override
       public ILoggerFactory getLoggerFactory() {
           return loggerFactory;
       }
   
       @Override
       public String getLoggerFactoryClassStr() {
           return loggerFactoryClassStr;
       }
   }
   

4. Package and use your binding
   Package these classes into a jar, add it to your project’s classpath, and exclude the official log4j-slf4j-impl dependency (since you’re providing your own binding).

Why Option 1 is Better #

Option 1 is far lower maintenance:

• You reuse the official log4j-slf4j-impl binding, so you don’t have to keep up with SLF4J interface changes.
• All Log4j2 features (like configuration, filters, and context management) work out of the box.
• No need to maintain a custom fork of any library.

内容的提问来源于stack exchange，提问作者madhu_since93