Revamp AbstractLogger in log4j-kit

[ppkarwasz]

In order for Log4j Core 3.x not to depend on the utility classes in Log4j API 2.x, we provide a new AbstractLogger in log4j-sdk.

The main improvements to this AbstractLogger are:

• The methods are grouped by functionality: public API for users, location-aware method for system integrators, "create Message and log" methods and filter methods. The most important methods are at the beginning.
• All the dependencies of the class (message factory, flow message factory, recycler factory) must be explicitly provided. Only the log builder implementation is hardcoded.
• The logMessageSafely message has an additional StackTraceElement parameter and all the logging methods are routed through it,
• All the methods are tested for their bytecode length so that most of them are below 35 bytes. The exceptions are listed in AbstractLoggerTest. It is basically impossible for unrolled vararg methods with more than 2 parameters and methods that use supplier to follow a 100% inline-able path.
• The class is annotated with JSpecify.
• The class has only 2 unimplemented methods: doLog (formerly log) and isEnabled(Level, Marker).

Part of #2290

[garydgregory]

"SDK" implies to me something big, not an API, while "SPI" implies something like a template to be implemented or classes to be extended.

[ppkarwasz]

"SDK" implies to me something big, not an API, while "SPI" implies something like a template to be implemented or classes to be extended.

I don't like calling things SDK either, but I like a simple rule to determine the main package name from the artifact name. o.a.l.l.spi is already taken, what about log4j-spi3 and o.a.l.l.spi3?

[vy]

Please no enumerated naming, e.g., log4j-spi3.

I am fine with log4j-sdk. Other alternatives I can think of:

• log4j-runtime
• log4j-backend
• log4j-kit
• log4j-base

[ppkarwasz]

@garydgregory,

What name would you propose?

Regardless of the naming of the artifact can you review the AbstractLogger class? There are some new methods like logEnterMessage, logCatchingMessage and so on. The most important ones should be at the top.

Since this PR targets the feature branch feature/log4j-sdk and not main, we can solve the naming problem just before merging the feature branch into main.

[vy]

This change is massive; maybe not in size, but its implications. I am not able to see anything fishy. But I guess we will iron out most wrinkles along the way.

[ppkarwasz]

@vy and @garydgregory,

I renamed the module to log4j-kit. Is it OK with you?