commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elijah Zupancic <>
Subject Re: [logging] logging vs slf4j
Date Mon, 08 Aug 2011 20:56:13 GMT
I agree with this sentiment. In the last 3 years all of the large
commercial projects that I have worked on used slf4j just for the very
reason that I needed to bridge the logging implementations in multiple
third-party libraries.

While reading this thread, one approach occurs to me that hasn't been
mentioned. Why not abstract the abstraction? My gut reaction to this
approach is negative, but I do feel that it is quite pragmatic.

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?

> 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:
For additional commands, e-mail:

View raw message