| Re: [jakarta.ee-spec] Proposal: Jakarta Logging |
Hi David,
Generally agree with the sentiments of Ed and Emily. This xkcd cartoon always comes to mind https://xkcd.com/927/ Do you have any thoughts on potentially not adding a new API, instead using an existing set of interfaces from say JUL, and shifting focus entirely on requirements for the implementations themselves? It could avoid API duplication/fragmentation while still raising the bar on implementations to deliver additional functionality. Ultimately a great deal of what standards require of implementations doesn't show in the API method calls and are done transparently behind the API. If that could be done here, it might address a lot of duplication concerns.
I think you touched the heart of the problem with current logging APIs: most of them are not precisely specified and the way a log statement is treated depends on the logging implementation used. Questions like "What will happen if I log a JAXB or JSON-B annotated object?" have no definitive answer and users that log POJOs in their code expect different (sometimes contradictory) behaviors.
As far as I am concerned, the group might concentrate on just
specifying the requirements for a logging implementation to be
Jakarta-aware or Jakarta-compatible. Note that JUL is probably not
a good reference, since it is mostly used by projects that only
log statements occasionally. The majority of the ecosystem (50-60%
by my estimates) uses SLF4J. If we add APIs with very similar
method signatures (Apache Commons Logging, JBoss Logging, Log4j
API, which have simple rewrite rules from SLF4J[1]) that estimate
goes over 90%.
[1] https://github.com/openrewrite/rewrite-logging-frameworks
* integrate with the observability and context propagation standards offered by Jakarta and MicroProfile,Do you imagine any of this being exposed to users as API calls they must make, or can these be solely guarantees an implementation offers and the spec and TCK requires?
The integration with metrics and tracing probably only requires to be guaranteed by the implementation.
Context propagation is a different (hot) subject. Over the past few years (starting with the release of SLF4J 2.0.0) there have been several attempts to improve the Mapped Diagnostic Context inherited from Log4j 1 and some are still ongoing (in SLF4J and Log4j API). Personally I have the impression that the need for context data in log events can be replaced with span attributes and the OpenTelemetry Baggage API, but there might be some use case I am missing (e.g. [2]).
If context data is still needed at a logging level, API calls could require some modifications, e.g. a Spring Reactor Context or Kotlin Coroutine Context might be passed explicitly to the log statement.
[2] https://github.com/open-telemetry/oteps/pull/207
* 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.This one definitely sounds like an implementation detail that could be a spec requirement that doesn't need to show up in the API the user used.
I agree, this should be entirely transparent to the user. Right
now it isn't and it requires complex application server specific
configuration in the generic case[3] or extensions for some
Jakarta servers (e.g. my personal extensions for Tomcat[4]).
[3] https://logging.apache.org/log4j/2.x/jakarta.html#log-separation
[4] https://oss.copernik.eu/tomcat/3.x/
* offer dependency injection, like in other eco-systems (.NET for example).This also sounds like something that could be a requirement delivered against existing APIs. CDI for dependency injection, JUL for users to make the actual logging calls and perhaps a couple annotations defined by the spec to ensure the right thing is injected.
I agree, although I wouldn't use JUL as logging API. In web applications we might expect a mixture of loggers obtained through injection and static method calls (e.g. in libraries that can be used outside of a Jakarta environment). JUL currently hides the information about its callers, which makes the determination of the appropriate logger very hard. As far as I know Tomcat and WildFly go through a lot of hoops and hacks (like the thread context class loader) to overcome this limitation.
Piotr