[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec] Proposal: Jakarta Logging
|
> On Oct 9, 2024, at 2:47 PM, Piotr P. Karwasz via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> wrote:
>
> 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.
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.
> * 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?
> * 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.
> * 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.
This is all just brainstorming of course. Curious on your thoughts.
-David
