[
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
