On Tue, 11 Dec 2007 11:12:05 -0800 "Scott Peters" <[EMAIL PROTECTED]> wrote:
> 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. :^) But why? JDK logging is always available. It's the responsibility of any good logging framework that has existed since 2001 to install a JDK LogManager in my opinion. I'm not saying that your idea isn't workable - it could probably be done (like you say, other projects already do this). It just seems more complicated than it needs to be. But I'll accept any solution that gets rid of the dependency. :-) - DML > -----Original Message----- > From: David M. Lloyd [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 11, 2007 11:06 AM > To: [email protected] > 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
