Quantcast
Channel: Liquibase Forums
Viewing all articles
Browse latest Browse all 2993

Re : Logging Changes

$
0
0
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?
that will be a problem for custom plugins that don't mess to much with logging but simply provide additional dsl elements or features for other databases. I'd suggest to at least keep a compatibility layer until Liquibase 4.
  • I m not sure why you introduced the LoggerContext
MDC/NDC are a well known concepts and the only benefit seems to be the AutoCloseable implementation. Is this because Liquibase is a single threaded use case and we have no ThreadLocal cleanup, that is usually used with MDCs?
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:
  1. LoggerFactory factory ...
  2. try(LoggerContext mdc = factory.createContext()){
  3.     mdc.push(key, value)
  4.     // other code
  5.     mdc.pop(key)
  6.     mdc.push(key2, value)
  7.     // even more code
  8. }
This will enable the use of multiple keys in one MDC, you can also provide a "pop(key)" method and you can clearly do something with the context. Pushing, poping and closing are located in one place and are not spread across the LoggerFactory and the context.

After all even though AutoCloseable is a nice to have feature, it does not seem so much different to:
  1. try {
  2.   MDC.push(key)
  3. finally {
  4.    MDC.pop(key)
  5. }
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

Viewing all articles
Browse latest Browse all 2993

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>