Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove dependency on logula. #161
What are your thoughts on removing the logula dependency?
My thoughts are:
The current logging doesn't seem very clean anyway: logula sets up appenders, only to have the maven plugin remove them, and replace with something else. It seems better if the sbt/maven/cli plugin set up logging, rather than the module.
While I was preparing this patch, I noticed that the integration tests seem to run without logging configured at first. I was running it by using
Erm. Yes and no.
The parts of logula we're actually using are the Log#forName method (which simply delegates to Logger.getLogger()); some code to set up a console appender; and a Formatter class. The parts we need can be implemented in about 20 lines. So yes in that sense.
(The Log class in the patch is a bit bigger than that because I've moved log configuration out of Module.scala).
No in the sense that the patch doesn't implement another wrapper on top of log4j. Instead logging calls go directly to the log4j logger. Right now, scalaxb isn't using any of the message formatting stuff that logula provides: instead it formats its own logging statements.
There is a middle-ground which would be using logula for logging, but not for log4j configuration. That wouldn't solve the third-party repository problem, but it would avoid some complexity in the maven plugin (and avoid using a superfluous AsyncAppender).
I am not necessarily against re-implementing logula. I just wanted to understand what we're getting ourselves into.
I saw that you had problems with slf4j, but only on twitter, so I never understood the exact problem you were having.
Do you mean that you want to programmatically configure appenders and logging levels, rather than a config file on the classpath?
Or do you mean you want to programmatically configure which logging backend to use, rather than having the classpath determine it?
The first is possible with slf4j. I doubt it's possible with the second.
On both counts, but mostly the latter. The logger got messed up whenever it was executed on modified class loader like specs and sbt. Basic things like changing the log level also couldn't be done programmatically without going down to the underlying logger, rendering the point of facade moot.
One thing facades like logula and slf4j do provide is conditional formatting, which log4j (on its own) doesn't. For example:
For scalaxb, the logging can be configured by the cli and build plugins, meaning most of scalaxb can just assume it's configured.
I went back to the commit before the change to logula, and added a logback-test.xml to the integration test project:
When I did that, the integration tests ran under sbt with debug logging. Other than also making it programatically configurable (for verbose output), what else would need to work? Or rather… how do you run the tests? :)