commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Petrelli <>
Subject Re: [logging] logging vs slf4j
Date Wed, 03 Aug 2011 15:01:31 GMT
First of all, sorry to jump in at this point of the discussion.

2011/7/28 Simone Tripodi <>

> Hi all guys,
> I remember I raw a thread - not sure if I did it here at commons or
> somewhere else here at apache - where specified we prefer adding
> [logging] as components dependency instead of slf4j...
> Did I just get crazy or someone can point me to the right direction please?
> :)

I think that we should start from the fact that many application developers
use Log4j 1.2 for their purposes, simply because it is *enough* configurable
and *enough* useful.
Sincerely I think that we don't need anything more than what Log4j 1.2
already provides.
And I don't think that j.u.logging is useful enough, the configuration is
simply not there.

Stated this, obviously it is out of the question to adopt Log4j, simply
because Commons is made of libraries, and other libraries use other logging
frameworks. So we need a wrapper.
I would choose SLF4J for a simple consideration: there is a Commons Logging
substitute in SLF4J (jcl-over-slf4j) but not a SLF4J substitute in Commons
>From a Maven perspective, If Commons Logging is chosen, when a common
library is included, SLF4J users must exclude commons-logging dependency to
add jcl-over-slf4j, for all libraries.

However in my experience SLF4J has a big drawback: when used in a shared
classloader (JBoss Portal anyone?) it is needed to have the same stinky old
version of SLF4J in all applications during compile time, and the library
should be excluded from the package.


P.S. The world was better when there was only Log4j :-D

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message