commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raman Gupta <>
Subject Re: [logging] logging vs slf4j
Date Mon, 08 Aug 2011 19:49:35 GMT
On 08/08/2011 03:28 PM, Matt Benson wrote:
> On Mon, Aug 8, 2011 at 2:23 PM, Paul Benedict <> wrote:
>> On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta <> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message