[PROPOSAL] Change Geode Log4J2 appenders to avoid programmatic add/remove

[Kirk Lund <kl...@apache.org>]

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

Re: [PROPOSAL] Change Geode Log4J2 appenders to avoid programmatic add/remove

[Jens Deppe <jd...@pivotal.io>]

+1 on this approach!

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

--Jens

On Thu, Sep 13, 2018 at 10:01 AM Kirk Lund <kl...@apache.org> 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] 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
>