On 08/08/2011 03:28 PM, Matt Benson wrote: > On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict <pbened...@apache.org> wrote: >> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta <rocketra...@fastmail.fm> wrote: >>> Perhaps I'm missing something, but what exactly is wrong with simply >>> using slf4j? It is an extremely simple, widely used library that >>> provides out of the box hooks for many logging frameworks including >>> log4j and logback, simple to configure (i.e. drop the appropriate jars >>> in and thats it), and works out of the box in an OSGi environment? The >>> only downside appears to be that it is not an Apache project. So what. >> >> The biggest issue I have with SLF4J is figuring out the dependencies >> that I need. I really detest having an API jar and then an >> implementation/bridge jar. I find that too annoying.
This is nothing new -- commons-logging requires the commons-logging.jar for library creators, and users need commons-logging.jar plus an implementation jar. Slf4j requires the same: slf4j-api.jar for library creators and an implementation jar for users. The bridging jars are *optional* and only required by users to bridge from jcl, jul, or log4j. > In fairness, using a dependency manager with support for transitive > dependencies you should only have to specify the implementation jar. > In the case of slf4j you may have to provide multiple jars (impl + > bridge X n logging frameworks in use throughout your application), > however. Of course, log4j v2 will have to support this paradigm in > some fashion or lose runtime "market share" due to slf4j's ability to > cater to the "lowest common denominator." Yes, the reality is large applications need to support multiple source frameworks and will therefore require a bunch of logging jars. Slf4j provides a relatively simple path to consolidating logs from jcl, jul, and log4j into one's chosen target framework (except for jul). With the current landscape, you are dreaming if you think one magical jar is going to support all use cases. This would have been simple if jul had been designed properly, but it wasn't. Cheers, Raman --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
