I am attempting to modularize Log4j and am running into some trouble understanding how this can work.
Log4j supports many Appenders, such as the FlumeAppender, KafkaAppender, CassandraAppender, and JPAAppender. Each of these use their respective libraries to cause the log events to be delivered to their destinations. All of these frameworks perform logging and so would have a dependency on a logging framework. For example, the FlumeAppender passes the LogEvent to an embedded Flume agent that then sends the event to a remote Flume node. The embedded agent performs logging using the Log4j 1 API and also uses other libraries that perform logging. So if Flume was modularized it would require some logging module. That module would almost certainly route logging calls back to Log4j 2 and so would require Log4j 2 and result in a circularity. In the same manner, the KafkaAppender uses the SLF4J API. When the implementation of that is log4j-slf4j-impl a circularity will occur. Since the Java module system forbids circularities I don’t understand how Log4j (or Logback) can realistically be modularized. We also noticed that System.LoggerFinder [1] now provides a new way to integrate an external logging framework with Java. If Log4j creates the service provider for that how will that not cause a runtime circularity since java.base now is bound to log4j-api and/or log4j-core and both of those require java.base. Ralph 1. http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging.html <http://docs.jboss.org/hibernate/orm/4.3/topical/html/logging/Logging.html>
