geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Deppe <>
Subject Re: [PROPOSAL] Change Geode Log4J2 appenders to avoid programmatic add/remove
Date Thu, 13 Sep 2018 22:40:05 GMT
+1 on this approach!

I'd like to work with you on this to get more familiar with our logging


On Thu, Sep 13, 2018 at 10:01 AM Kirk Lund <> wrote:

> 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]
> [2]
> [3]

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