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 21:13:02 GMT
On 08/08/2011 04:56 PM, Elijah Zupancic wrote:
> This could be done by choosing (dynamically or by configuration) the
> logger implementation log4j / commons / slf4j / jul and then loading
> the LoggerFactory into a wrapper class that is then called used by the
> Commons project.
> We would then make the logger implementations a compile-time
> dependency only and relay upon the consumer to provide them.
> I do realize that this is essentially doing a Facade on top of a
> Facade, but it solves the problem for consumers of the library by
> providing many options.
> So, am I crazy?

If I understand you correctly, you would have this dependency chain:

random-commons-project ->
  commons-logging-wrapper ->
    API like slf4j or logging implementation (at runtime)

Plus commons-logging-wrapper requires compile-time knowledge of all
possible target frameworks, since it is not coding to an API.

Can you explain the advantage over simply coding
random-commons-project against slf4j-api.jar? Then, you have this
dependency chain:

random-commons-project ->
  slf4j-api ->
    logging implementation (at runtime)

And anyone can create their own slf4j compatible logging
implementation simply by implementing the slf4j api and dropping their
jar into their environment.


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

View raw message