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? -Elijah > 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
