GoogleCodeExporter
commented
8 years ago 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?Original comment by lar...@gmail.com on 3 Apr 2013 at 6:44
- Changed state: Accepted
- Added labels: Component-Core, Type-Enhancement
- Removed labels: Type-Defect
Original issue reported on code.google.com by
yann.bar...@gmail.comon 27 Mar 2013 at 4:10