Usage of a logging framework

[cpeeyush]

EDC usages a custom logging framework (Monitor, Console Implementation) that is missing much essential functionality like:

• Package and class-level loggers (to control log granularity and provide the class name in logs)
• Guards e.g. if (logger.isDebugEnabled){} to skip expensive code, also required by linters such as PMD
• Parameter interpolation (to skip toString calls and provide analytical queries in Azure Log Analytics)

Probably SLF4J can be use as it is built precisely as a highly compatible layer on top of other logging frameworks and to provide that functionality. If that is not an option, JUL (java.util.Logging) can be used which is part of the JVM.

[jimmarino]

We decided not to select a specific logging framework and instead leave that to users to plug in their desired one of choice.

Regarding the specific points:

1. IMO there are better options than logging class name (which has very little operational value) such as including a more descriptive message or a stacktrace if there is an error. However, if someone wanted to do this in their own code, it can be done by wrapping the existing Monitor interface.

2. Guards aren't needed because the Monitor interface makes use of Suppliers. In typical scenarios, the performance of string formatting will not be an issue, particularly since most of these messages deal with error, info or warning conditions that will most likely need to be outputted. That's why the Supplier variants are not used much.

3. If there is a need for parameter interpolation we can added it, but given the existence of the Supplier methods, is it really needed? What specific requirements would this resolve?

[algattik]

Given SLF4J is already a dependency, why not use it? The motivation you quote is exactly the one behind SLF4J, and it seems advantageous to leverage existing work.

1. The notion of logger hierarchy is quite important in practice, to assign a particular log message to a specific component of an application, and provide granularity in controlling log levels.

2. Indeed increasing logging scope would greatly increase observability (Observability - Essential - Missing logging #420). Indeed it appears that Suppliers make guards unnecessary.

3. Parameter interpolation keeps code clean, helps mitigate injection attacks, and reduces the cost of string building. In log queries in Azure Monitor, each of the parameters is loaded in a custom field next to the uninterpolated which allows building analytical queries.

[algattik]

Another comment: the name Monitor used in EDC to mean Logger is confusing, this is not about monitoring.

[jimmarino]

@algattik We have already decided not to use a particular logging framework. The dependency on SLF4J is there because of a third-party library and I would like to remove that.

Regarding the issues, please discuss concrete requirements and we can address those. I'm going to close this issue as we have already addressed this decision.