Geode currently manipulates Log4J2 at runtime to add/remove Appenders based on the Cache lifecycle. While working on GEODE-5637, Sai and I tried to add ListAppender [1] from log4j-core test-jar programmatically at runtime using the same code that Geode uses for AlertAppender, LogWriterAppender and removing/adding STDOUT ConsoleAppender. Unfortunately, this behavior seems to either have never worked completely or was broken by one of the Log4J2 dependency upgrades over the last couple years.
In my opinion, it doesn't make sense to continue in this direction. GEODE-2644 describes an alternate approach which would be easier to maintain and more user-friendly in the long-run, so I'm planning to change the Geode appenders as described by GEODE-2644 and then add debug functionality to the Geode appenders which tests such as this can use for easier testing. Old approach: The Geode Appenders are added or removed when the Cache is created or closed. Geode uses Log4J2 Core APIs to reconfigure and updateLoggers, but updating of static loggers doesn't seem to be working as intended. New approach: The Geode Appenders would remain registered throughout the life of the JVM. The Appenders will contain mutable state that allows Geode to change its internal configuration or enable/disable output without resorting to programmatically reconfiguring Log4J2 at runtime to add/remove Appenders. We would also make the Geode Appenders optional and configurable from log4j2.xml, which allows users to use a different back-end such as Logback with Geode or to more easily tweak behavior of these Appenders when using Log4J2. I think this actually ends up being less work both in the short-run and long-run than trying to fixup the current approach. If anyone has concerns or opinions or wants to be involved, please reply to this thread. Thanks! [1] https://issues.apache.org/jira/browse/GEODE-5637 [2] https://relentlesscoding.com/2018/04/21/unit-test-log4j2-log-output/ [3] https://issues.apache.org/jira/browse/GEODE-2644
