[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec] Proposal: Jakarta Logging
|
Hello,
I would like to respond to the general statement "please don't introduce another logging API".
Three committers to this proposal are also Log4j members. We are currently working on Log4j 3. Maybe it is not well known, but Log4j 2 already has a separate API. With 3.x approaching, we will have *another* API.
We want to avoid introducing yet another API. That is why we propose a project that will not add another one, but make the Log4j 3 and also hopefully the Log4j 2 obsolete and Log4j is using the standard Jakarta API natively. With that move we hope that other Logging solution providers will follow.
I’ve seen the xkcd comic about competing standards. If Jakarta does not pass this proposal, we’ll end up with more 'standard' APIs, including one for Log4j 3.
We, the three people that initiated this proposal, want to unite the community, and no longer compete between Log4j API and Slf4j API. Being in the Log4j community for 15 years and experiencing log4shell first hand I think it is long overdue.
The Java world, in my opinion, urgently needs a common API that ends the logging framework discussion and let's everyone switch their provider as they please.
Thanks
Christian
On Sun, Oct 13, 2024, at 20:48, Scott Stark wrote:
Red Hat would disagree with the current project scope as it is introducing yet another logging API and/or implementation. We can't really understand why this is appropriate for Jakarta EE to consider. If it was a proposal to introduce a CDI event mechanism to bridge into logging providers, that would be something to look at, but a replacement for log4j/slf4j does not make sense to us.
Dear Jakarta EE Specification Committee,
I propose "Jakarta Logging" for the Jakarta EE ecosystem.
You can find the proposal here:
This project seeks to streamline logging practices across the Java community by providing a standardized API. This approach aims to:
- Enhancing security by minimizing dependencies and reducing risks as seen with the Log4shell vulnerability
- Eliminate incompatibilities between logging frameworks
- Remove vendor lock-in by encouraging adoption of the Jakarta Logging API
- Simplify configuration, reducing the need for bridges
- Motivate frameworks to leverage the Jakarta API rather than building their logging solution
The proposal is backed by three members of the Log4j team who have extensive experience working on the framework full-time. We would love to bring our experiences to Jakarta EE and hope others will join us in this effort.
If you are interested in becoming an initial committer or want to contribute in another way, please reach out to me by e-mail and I will happily add you to the proposal.
In addition, if you have any questions, I will gladly address them by e-mail or during a Q&A call.
I am looking forward to your feedback!
Kind regards,
Christian
_______________________________________________
jakarta.ee-spec mailing list
