Hi Nathan,
sorry for the long delay, I finally took some time to look at the recent logging changes. Here are some things that came to my mind:
- why rename the LogFactory?
- I m not sure why you introduced the LoggerContext
Creating something with a "push" method and freeing it up with a "close" feels awkward, too.
If you like that abstraction of a MDC, why not do something like this:
- LoggerFactory factory ...
- try(LoggerContext mdc = factory.createContext()){
- mdc.push(key, value)
- // other code
- mdc.pop(key)
- mdc.push(key2, value)
- // even more code
- }
After all even though AutoCloseable is a nice to have feature, it does not seem so much different to:
- try {
- MDC.push(key)
- finally {
- MDC.pop(key)
- }
and this would not need the creation of another object.
What do you think?
- I am very skeptical about the LogTarget
Liquibase has a good separation of concerns. Usually no Change ever outputs any Sql directly but let some factory create it and Executor run it. The LogTarget seems to imply that one class/logger will be used to output user information, debug info, read sql and write sql. Actually I don't think this is a common use case.
Just a guess: some user wants to suppress some of the logging caused by a verbose third party extension. But by lowering the LogLevel he also mutes the output of generated SQL and the CLI output and not just the stuff written to the log file. Most messages in liquibase are on a info level, but many production environments encourage warn level.
I havent used Log-Markers (even log4j2 seems to have them) so this may be only a concern cause I am only used to LogLevels for filtering messages.
Hope my remarks help and are not too critical, I really appreciate your work and the fresh breeze from dbmanul.
kind regards
Daniel