geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <>
Subject [PROPOSAL] Change Geode Log4J2 appenders to avoid programmatic add/remove
Date Thu, 13 Sep 2018 17:01:37 GMT
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

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

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

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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message