A few comments on the list of points against slf4j below... On 08/08/2011 05:58 PM, Elijah Zupancic wrote: > From what I can tell from the thread, here are the following points > against SLF4J: > > * Log4j developer V2 would like to see the Apache community support > the project rather than putting resources into slf4j.
Keep in mind that slf4j is not a logging framework -- it is only a facade that provides: 1) an API 2) (optional) bridges from jul, jcl, log4j to a target framework of choice I think there may be some confusion with Logback. Logback is the logging framework created by Ceki that *implements* the slf4j API, but is a separate project and using slf4j creates no dependency on Logback. > * Slf4j apparently has some deficiencies in its API such as: "SLF4J > has to convert the EventData object to XML since SLF4J/Logback don't > provide a good way of handling this." If this is truly an API deficiency (i.e. SLF4J, not logback), then AFAICT every other current logging API has the same deficiency, including log4j, jul and jcl -- since they are all pretty similar. IOW, very few users will care. > * Log4j V2 also implements support for the Slf4j API. Great. This is an advantage of coding commons components against slf4j since both logback and log4j v2 can both be used out of the box with a native implementation of the slf4j api. > * There is a hassle with too many jars for dependencies with slf4j. I addressed this previously. There is no alternative solution that is simpler. If jul had been implemented as an API (like slf4j) then we'd only need one jar. Alas... > * Every time Ceki goes on vacation everything stops. Again, we are talking about an API. It rarely changes. There is little reason for it too change, and many reasons for it not to change. > * Some have a preference for Apache driven projects. OK. > * Figuring out the dependencies that are needed can be difficult. It's actually really simple. Far and away simpler than commons-logging. For writing a library, you need one jar: slf4j-api.jar. That's it. For developing an application, here are the dependencies in a nutshell. This should cover every common situation. Pick your desired situation, and put the jars specified on your classpath - done. 1) I want all log statements to go to log4j v1: slf4j-log4j12.jar log4j.jar 2) I want all log statements to go to log4j v2: log4jv2.jar (the above is a guess based on your statement that log4j v2 implements the slf4j-api) 3) I want all log statements to go to logback: logback-core.jar logback-classic.jar (optional) logback-access.jar (if logging web access logs) 4) I want all log statements to go to jul: slf4j-jdk14.jar 5) I want all log statements to go to jcl: slf4j-jcl.jar For *all* of the above, add: slf4j-api.jar (optional) jul-to-slf4j.jar (if using libs that call jul) (optional) jcl-over-slf4j.jar (if using libs that call jcl) JCL only supports option #1 and #4 (I think) and uses one less jar in those cases. > If we can come to some consensus regarding this issues, then I think > there will be more traction toward Slf4j. Cool. Given the above list, I don't really see any issue with coding commons projects against the slf4j api. Except perhaps the "it's not made here" thing. If that is a problem, then as I said JCL is fine and easily bridged to slf4j and thence to any desired framework. Cheers, Raman --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
