Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] Proposal: Jakarta Logging

Hi Emily,

On 8.10.2024 13:34, Emily Jiang via jakarta.ee-spec wrote:
Hi Christian,
Thanks for writing up the proposal!
As far as the Logging is concerned, there is no lack of logging frameworks and the communities have resistance to the convergence on any of the choices. MicroProfile community discussed whether to standardise Logging. After a lengthy conversation, the consensus was that there were many frameworks already. It is better to use Log4j or SLF4J or JUL. OpenTelemetry has Logs support together with Metrics and Tracing, which even avoided defining yet another logs API by instead using your own logs API. With this, I do not think this is something we should invest nor support.

I agree that the Java world is very polarized regarding their logging API choices. This leads to a situation, where each application needs at least 2 bridges (better 3 or 4) from "foreign" logging APIs.

My personal motivation for this proposal is the observation that all the major logging APIs (SLF4J, Log4j API, JBoss Logging) are maintained by the same person or group that maintain the corresponding logging implementation (Logback, Log4j Core, JBoss LogManager). This causes a situation where changes to an API are motivated by changes in the single native implementation. Bringing this proposal to the Jakarta is an effort to break this cycle and to require a larger group of experts to make changes to a logging API.

Note that in January the Apache Log4j project decided not to publish a Log4j API 3.x, but to keep a mostly frozen Log4j API 2.x as base for all major version of the Log4j Core implementation. Introducing a new Jakarta Logging API will only temporarily increase the number of common APIs, since the plan is to abandon the Log4j API shortly after.

Most logging APIs were designed decades ago, when logging was responsible for tracing, metrics and context propagation. I strongly feel the need for a newer API that would:

* integrate with the observability and context propagation standards offered by Jakarta and MicroProfile,

* offer a good separation of logs into domains for multi-user servers. These features are not very well supported by modern logging frameworks and Logback even dropped the support for multiple logger contexts 7 years ago.

* offer dependency injection, like in other eco-systems (.NET for example).

Piotr




Back to the top