Description

This is a meta-issue tracking subtasks required to introduce a lightweight logging API for use by plugins.

The lightweight logging API offers plugins a stable API upon which to depend. The logging API will facilitate the logging needs of plugins without those plugins depending on any particular third-party library, or server internals. Moreover, any third-party logging library, like say Log4J, will be removed from the class loader hierarchy available to plugins.

The logging API is a small lightweight facade that locates a concrete implementation through an SPI. The logging API is agnostic of any other underlying logging library, like say, Log4J. The implementation however may use Log4J, or another popular logging library. The logging API has no dependency on server, it may however have a dependency on other libs like say, core or x-content (but care must be taken to reduce any dependencies as much as possible).

Stable plugin API

• Introduce basic usage for stable plugin API Stable logging API - the basic use case #86612
• Logging api with Messages (ESLogMessage)
• DeprecationLogger
• Prefix logger
• Move log4j off the system classloader (Implement subproject impl which has the log4j dependency)

ES dedicated logging api

• Logging Bootstrap
• Creating appenders
• Examine Logging audit trail

Refactorings

• Remove context sensitive getLogger calls that do a stack walk. (Replace stack walking getLogger with explicit calls #84480)
• Remove usage of ParameterizedMessage Remove usage of ParameterizedMessage in server #86549
• log4j utilities that are not used in logging context - Strings, Throwables
• Refactor logging bootstrap and Loggers into ES dedicated api
• Refactor "internal" plugins to use ES logging api Change plugins to use elasticsearch logging #90227

Testing

• testing - ideally to not rely on log4j. More time consuming tests - EvilLoggerTests, CapturingLogger, JsonLoggerTests
• LoggerUsageChecker - possibly a refactor and expanding to cover String.format Static analysis tool for String.format #87166
• MockLogAppender - widely used in our testing. An appender with additional assertion capabilities. THe refactoring can be performed where the log4j appender code is moved into internal implementation and the expectation(asertion) code is within the core/testing package which is part of the exported API.

Bridges

• SLF4J -> ES_Logging API bridge
• Log4j -> ES_Logging API bridge (or we can decide to use the log4j<->sl4j bridge

More:

• Refactor and extrapolate logging configuration in server