I remember you mentioning the Ant issue, Daniel. My thought has been that slf4j is doing the same log indirection layer that we currently have/want, but in a more "standard" way. No use re-implementing something that works just fine. I liked the fact that the slf4j API can be bound to a variety of different logging systems depending on what the user wants to use. Commons-logging is a similar idea as well, but slf4j seemed to have some newer features that were nice.
I also don't mind if the CLI is tightly bound to the the logback slf4j implementation because I see that as more as a stand-alone tool that is ran independently and can have dependencies that are not in the core liquibase library, such as commons-cli and logback. Especially in Liquibase 4, I'm trying to build in a central concept of common "commands" which can be called by the CLI, Ant, Maven, etc. so that the CLI can truly be a stand-alone thin wrapper that does what it wants without affecting anything else.
In the end, however, I think what we need is an API that lets us do a few things:
- Plug into any logging implementation (java.util logging, log4j, etc.) so the Liquibase logs can be included in the rest of the application's logs
- Be able to provide a context (such as the current changeset, object being snapshotted, etc) that a log was created in
- Differentiate between DEBUG, INFO, WARN, SEVERE, and FATAL levels
- Capture executed SQL in a distinct channel
- Capture query SQL separately from "update" SQL
- Capture user error messages
- Capture system errors and stacktraces
- Capture "progress" messages like "executed changeSet 8 of 91"
What makes it difficult is that the goal is to have the vast majority of the Liquibase code the same whether it is ran through Ant or Maven or Spring or the CLI, which means the the business logic will need to be generating all that information without knowing how it will be used. It should be up to the end-point integration to be able to use the logging info as it needs. Ant, Maven and Spring would just log out whatever matches the log level. The CLI, on the other hand, is more complex because it would normally output just progress messages and user error messages, but for updateSQL, it should just output the "update" sql, and the user should be have it output stacktraces or additional logging if need be.
Perhaps that is all more than SLF4j or any other existing generic-logging system can already do on it's own. I was still experimenting a bit with how it could work in Liquibase 4, and once something got figured out there I would backport it back to 3.x as possible. I would maybe need to leverage the Command classes in addition to the logging system to get everything we need. Or maybe just still keep our own custom logging system instead of trying to write to someone else's system. And, maybe the Ant problem is a showstopper for slf4j in general.
So..... to connect back to the Logging changes in the merge.... I definitely agree that there needs to be changes to how logging is handled, but I think it is part of a larger change we need to make so I'm worried about pulling a partial change in 3.6 when we may make larger changes again soon. I think if we bring the changes in as they are, I think it would force us to work through the larger logging changes before we could release your changes. Or, we could pull the logging changes into a separate branch and look at the larger changes with 3.7.
Given that I was hoping to figure out better logging in 3.6 anyway, I think it is best to leave your changes in, but they may be refactored as part of a more complete logging change in 3.6. As part of that, we can make sure the pipe support still works and how throwables are handled.
Nathan