The Jericho html parser project allows for multiple logging systems to be used; SLF4J & Log4j being two of them. MINA could be modified to do the same sort of reflections lookup to determine which logging system is available. Just keep in mind someone may have to programmatically override the auto-detected logging system as we have here. :^)
Just a thought, -Scott -----Original Message----- From: David M. Lloyd [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 11:06 AM To: dev@mina.apache.org Subject: Revisiting logging in MINA 2.0 Hello fellow MINA users. I come before you today to hopefully change your collective minds on an issue that is causing me trouble, and is preventing two other big projects that I know of from adopting MINA for I/O. The issue is, of course, logging. The problem is simple: anyone who wants to use MINA must also have slf4j in their classpath to support logging. This is not optional. The reason that this becomes a difficulty is that MINA is a framework that is very attractive not only to your average end-developer, but also to other framework authors. As a framework author myself, I plan to use MINA for high-throughput network I/O - it's well-written, clean, and proven to be quite efficient. However, my framework, MINA, and another dependency of my project each use a different logging API, resulting in the need for the user to have two different logging JARs in the classpath in order to use my framework. It is my firm believe that ALL framework libraries that require logging should use JDK logging. The reason is simple: the user does not then have any external JAR requirement for logging, unless they CHOOSE to use a different framework. You may be thinking that by using JDK logging, you are somehow taking away the user's choice of logging frameworks. But this is not an accurate view of the situation. Even if the user doesn't want to use or configure JDK logging, there is nothing preventing the container or the user's log framework of choice from registering its own LogManager. Indeed just about every major container out there does this, and with good reason - many existing frameworks already use JDK logging. And why wouldn't they? It's a logging API that does the job, and it's been built in to every JDK since 1.4.0. In fact, by using JDK logging you INCREASE the user's ability to choose logging frameworks, by not requiring them to include a logging meta-jar of any sort. Even if you (MINA developers) will ONLY use slf4j, PLEASE make it optional somehow. Give the user the choice of not using slf4j rather than imposing it on them (and us, the developers who want to leverage MINA for our own frameworks). Please take some time to consider what I've said. If the slf4j dependency is made optional or removed, I know for a fact that several more projects will be using MINA for I/O that otherwise considered the logging framework issue a show-stopper. Thanks! - DML
