Duke
Duke copied to clipboard
larsga
Use log4j for output
From [email protected] on March 27, 2013 17:10:49
Evolution suggestion : use log4j for both console output & matches results
Original issue: http://code.google.com/p/duke/issues/detail?id=113
From [email protected] on April 03, 2013 11:44:08
Yeah, this is a good point. I'll try to explain why we are where we are now.
(1) I hate dependencies. I really want to have as few dependencies as possible. Right now there's only one: Lucene.
(2) Everyone wants to use different logging engines. Some people want log4j, others want commons-logging, others again want slf4j (or logback). Whichever one we choose, someone will be unhappy.
Even if they do use the same logger that we choose, people often get versioning issues where Duke uses version x.y.z of the logger, but they also use some module that uses version a.b.c. Wailing and gnashing of teeth ensues.
(3) Obviously, everyone wants to have proper logging, despite both (1) and (2).
So, how to solve?
We already have the Logger interface ( http://code.google.com/p/duke/source/browse/src/main/java/no/priv/garshol/duke/Logger.java ), which is used to implement logging in Duke. Basically, to get log4j logging, all you need is an implementation that "translates" to the log4j interface. Unfortunately, the naïve approach to that lands us in the soup with issues (1) and (2) above.
I'm wondering if the solution is to use a service provider interface (SPI) approach, like what slf4j does, and basically make a set of submodules. One submodule for each logging engine/version you want to use. In each of the .jar files we include a properties file that sets a property saying what class to instantiate. That way, you bundle one of the .jars with Duke, and Duke automatically logs to the engine that .jar uses.
We can then implement a log4j submodule with a Logger implementation in it, and be happy. If someone else wants another logging engine they can implement that and contribute it.
What do you think?
Status: Accepted
Owner: [email protected]
Labels: -Type-Defect Type-Enhancement Component-Core
From [email protected] on April 12, 2013 03:55:48
Hi Lars,
I'll take a look at the logger interface and try to give you my opinion...
The solution you present sounds like re-implementing slf4j.
What are the downsides of using slf4j? It already does what you describe with the upside of you not having to implement it and giving users the opportunity to use different loggers. I see your point with the added dependency but I would rather opt for less code to maintain.
Yes, it is pretty much reimplementing slf4j, with the difference that you can get the software to run without having the logging engine on the classpath. I really don't like any of the alternatives here, which is why I have left this one alone. Duke is used by a number of people who are not really very good at dealing with the classpath, and every dependency we add makes life harder for them.
Anyway, I agree that it's better to use slf4j than log4j.
I'd like to vote for slf4j. It's quite easy to use, very flexible, and people who don't want to be bothered by it can be directed to use slf4j-simple. It would be great to improve the output of information about what is going on because the current lack of it makes it harder to use. I personally had to go check the source code on several occasions already and even debug it. A bit more logging in a standardized way could help to prevent that.
