Re: [jakarta.ee-spec] Proposal: Jakarta Logging

["Piotr P. Karwasz" <piotr@xxxxxxxxxxxxxxxxxxx>]

Hi Werner,


On 16.10.2024 00:07, werner.keil--- via jakarta.ee-spec wrote:
> Markus Eisele, currently at Red Hat was hoping to get a logging JSR 
> into the JCP many years ago, but it did not even reach proposal phase.
> From what I recall the committers to SLF4J/Logback and Log4J could not 
> agree which one should be the RI, so as asked earlier in this thread, 
> would SLF4J participate in this effort now and eventually be happy to 
> have it replace major parts of its API?

Before I answer that it's probably useful to recall some differences 
between the SLF4J/Logback and Log4j team:


* SLF4J/Logback is a single maintainer project started by Ceki Gülcü. He 
is also the creator of Log4j 1. Except JUL, all the major Java logging 
APIs are either inspired by Log4j 1 or SLF4J. Honestly I do not know if 
anybody else has write permission to the SLF4J/Logback projects.
* Log4j 2 is an Apache project with a democratic governance. While 
Volkan and I have contributed over 90% of the changes in these past two 
years, every member of the team has a vote, including the right to a 
veto under some justified circumstances.


Together with Christian and Volkan, we have contacted Ceki a couple of 
months ago to work on a common successor to both SLF4J and Log4j API, 
that would be based on SLF4J 2.x. He was not interested at that time 
(and maybe with that team), but I don't exclude he would be willing to 
join a Jakarta working group.


It is worth noting that, while some members of the SLF4J/Logback and 
Log4j teams still advocate the superiority of their comprehensive 
logging solution, the market has validated that claim and the mixed 
SLF4J + Log4j Core configuration is very popular. Judging from the code 
examples provided by users in questions, a majority of them uses SLF4J. 
Some of them are motivated by the misconception that Log4j API does not 
offer multiple logging implementations, which has never been true 
(Logback has been supported from day 1), but I interpret this result as 
a quest for independence of the logging API they use from the 
implementation.

The main differences between SLF4J 2.x and Log4j API have either 
disappeared (SLF4J 1.x lacked support for structured logging) or have 
lost its previous importance (due to enhancement to garbage collectors, 
garbage free logging is not as important now).


Piotr