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
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
