Re: There is no log4j-slf4j2-impl in 3.0.0-beta3

Hi Pavel,

On 28.11.2024 13:47, PavelTurk wrote:
> Thank you very much for your help. I've understood how it works. I just wonder did you decide to go this way because 
>
> you plan to continue version 2?
>
In January this year we decided not to continue the development of Log4j 
API 3.

The reason for this decision is simple: for a logging API it is 
unrealistic to assume that users can move all their code and 
dependencies from Log4j API 2 to Log4j API 3 at once. If we want 
breaking changes in Log4j API 3, we have two choices:

1. We can use a new package name. For me this means: introduce yet 
another logging API.

2. We can make no breaking changes.

We chose the second, so we decided we might as well call it Log4j API 2 
and stress the independence of the API from the implementations. SLF4J 
has one native implementation, Log4j API 2 will soon have two (Log4j 
Core 2 and Log4j Core 3).

Regarding version 2:

* Both Log4j API 2 and Log4j Core 2 will be supported for a long time.

* Log4j API 2 will be actively developed for the foreseeable future. 
This means: at least until we find a successor. Personally I would like 
the next logging API to be developed in collaboration between multiple 
implementers and users, so we can stop this logging API war that has 
been going on for years. An external standardization body that 
guarantees to maintain the API after we all retire would be ideal for 
this purpose. Together with Christian and Volkan we reached out to 
Jakarta[2], but judging from the answers, a Jakarta Logging API is 
unlikely to appear.

* We didn't discuss the details yet, but Log4j Core 2 might switch to 
"bug-fixes only" and then to "security-fixes only" some time after the 
first 3.0.0 release.

Piotr

[1] https://lists.apache.org/thread/p2lgr3xtt9hq77j7r67r8x1tc1z7kbol

[2] https://www.eclipse.org/lists/jakarta.ee-spec/msg03511.html