[MS11] Log4j API generalization #2

[ppkarwasz]

Following the conclusion of #2273, we continue our task of removing version 3.x of log4j-api and replace it with version 2.x.

This task requires changes in both the 2.x and main branches.

Changes to Log4j API 2.x

Since log4j-api is not a pure API artifact and contains a lot of utility classes, we need to create extension points that will allow Log4j Core 3.x to replace the utility classes from log4j-api that require breaking changes.

All the functionality accessible from the org.apache.logging.log4j package (the public API) is provided by five services:

• LoggerContextFactory provides the functionality of the LogManager static methods,
• ThreadContextMap and ThreadContextStack provide the functionality of the ThreadContext static methods,
• MarkerManager is a non-customizable service that handles the creation of Markers,
• Level is a non-customizable service that provides support for custom log levels.

Of these five services, only LoggerContextFactory and ThreadContextMap need to be provided by a logging implementation.

While in Log4j Core 2.x these services can be created independently and access each other through the LogManager/ThreadContext static methods, in Log4j Core 3.x they are linked together by a common dependency injection context and need to be created by a common factory.

Therefore we need to:

• Centralize initialization in Provider class #2374, which is the common factory that creates the LoggerContextFactory and ThreadContextMap,
• Backport some Log4j API 3.x features #2392

Changes to Log4j Core 3.x

The lion's share of this task concentrates on Log4j Core 3.x, which must incorporate all the enhancements that are currently part of Log4j API 3.x. Currently the main differences between Log4j API 2.x and 3.x are:

• the Recycler API introduced in [MS6] Unified memory management #1 #1969,
• an enhanced version of PropertiesUtil

We decided to move those parts of Log4j API 3.x into a new "utility class"-only Maven artifact log4j-kit, that can be shared between Log4j API implementations the same way log4j-api 2.x is, but will allow for breaking changes between major versions, without affecting the end users.

The plan for the new artifact is log4j-kit:

• Revamp AbstractLogger in log4j-kit #2291: AbstractLogger has evolved during the lifetime of log4j-api 2.x, but due to backward compatibility constraints we were not able to add features like user-provided location in an uniform way. We can refresh AbstractLogger in log4j-kit and improve its performance.
• Add PropertyEnvironment to log4j-kit #2307: we decided to drop the initial property enhancement implementation from Log4j API 3.x and write a new one similar to the one in Spring Boot,
• Replace PropertiesUtil with PropertyEnvironment #2396
• Move Recycler to log4j-kit #2400
• Rebase Log4j Core 3.x on Log4j API 2.x #2410
• Remove Log4j API 3.x #2411

Since this task requires widespread changes in Log4j Core 3.x code, we can also perform these maintenance tasks:

• Generalize DI usage #2366

[grobmeier]

Checked, thanks!