In IDEasy we have created our own logger below IdeContext.
This has some special feature and somehow makes sense since what we want for the regular end-user is something different than what a regular logger provides...
However, from a design PoV (and during JUnits) regular logging via SLF4J has several advantages:
logger can be defined as static final constant simplifying dependencies (no IdeContext must be passed to constructor of every class that wants to log something)
during the tests we can see which class was triggering the logging
On the other hand we have some edge-cases that cannot be easily addressed by SLF4J:
custom log-levels like step or interaction
advanced test-support where we can assert that specific lines or fragments have been logged
The idea of this story is to analyze and after agreement also implement some improvement to our logging.
Currently I am thinking about a hybrid approach:
What it any class in IDEasy could also log with SLF4J - During JUnits we would then use logback see the regular log output including the Class containing the log statement.
By implementing our own SLF4J Bridge Implementation, we could make SLF4J log to our custom logger in regular IDEasy CLI usage.
We could investigate if SLF4J API & core would work in GraalVM (what should already be sure) and still not increase our footprint (native-image size, performance, memory consumption, etc. - what is also 99% likely). If results are fine, we could decide for this apprach and include SLF4J into IDEasy.
We could even evaluate if SLF4J API can somehow support custom log-levels (e.g. via Markers). Otherwise I would suggest an hybrid approach where the current ldeContext logger remains as is and we add a SLF4J Bridge that delegates to it (in the worst case we would again need to go back to a static instance variable holding the latest IdeContext instance like we had before).
In IDEasy we have created our own logger below
IdeContext. This has some special feature and somehow makes sense since what we want for the regular end-user is something different than what a regular logger provides...However, from a design PoV (and during JUnits) regular logging via SLF4J has several advantages:
IdeContextmust be passed to constructor of every class that wants to log something)On the other hand we have some edge-cases that cannot be easily addressed by SLF4J:
steporinteractionThe idea of this story is to analyze and after agreement also implement some improvement to our logging. Currently I am thinking about a hybrid approach:
IdeContextinstance like we had before).Wouldn't that be a great improvement?