[ 
https://issues.apache.org/jira/browse/GEODE-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685797#comment-16685797
 ] 

ASF subversion and git services commented on GEODE-2644:
--------------------------------------------------------

Commit 02c3cae1d38098259ff6aa4635c6e74f795bdc50 in geode's branch 
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=02c3cae ]

GEODE-2644: Make AlertAppender optional and support log4j2.xml

AlertAppender is now configured in log4j2.xml and it supports sessions
that correspond with Cache lifecycle. This allows Geode to pause and
resume AlertAppender without resorting to dynamically adding and
removing appenders.

List of changes:
* Change AlertAppender to be pausable and session-oriented
* Make AlertAppender support configuration from log4j2.xml
* Log4j2 Core dependency is now optional
* Internal Alerting interfaces allow Alerting service to be pluggable
* Reduce coupling between Alerting and the rest of Geode
* Greatly increase test coverage for Alerting


> Provide ability to configure Geode appenders in log4j2.xml
> ----------------------------------------------------------
>
>                 Key: GEODE-2644
>                 URL: https://issues.apache.org/jira/browse/GEODE-2644
>             Project: Geode
>          Issue Type: Improvement
>          Components: configuration, logging
>            Reporter: Kirk Lund
>            Assignee: Kirk Lund
>            Priority: Major
>              Labels: AlertAppender, Log4j2, LogWriterAppender, log4j2.xml, 
> pull-request-available
>          Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> Presently Geode dynamically creates, adds and removes AlertAppender and 
> LogWriterAppender by manipulating log4j2 core API. We should move the bulk of 
> the Appender functionality to internal classes and just leave the Appenders 
> registered with log4j2 during the life of the JVM. 
> This allows us to enable and configure our Appenders via log4j2.xml and 
> control the Cache-controlled lifecycle internally without having to add and 
> remove custom Appender instances.
> The code would then become simpler, we could avoid invoking log4j2 core APIs, 
> and users would have control over configuring our use of log4j2 completely 
> within the .xml file. Presently, a user cannot configure our AlertAppender or 
> LogWriterAppender in log4j2.xml.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to