[
https://issues.apache.org/jira/browse/GEODE-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632196#comment-16632196
]
ASF subversion and git services commented on GEODE-2644:
--------------------------------------------------------
Commit 8c7a7396f992d96e8086d6492e25c97c2092a3da in geode's branch
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8c7a739 ]
GEODE-2644: Cleanup LogService (#2533)
* Rename LogService getConfigInformation to getConfigurationInfo.
* Rename variables, remove SuppressWarnings, remove unused code.
> 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: 4h 20m
> 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)
