On Wed, 12 Dec 2007 10:50:49 -0800 Brian McCallister <[EMAIL PROTECTED]> wrote:
> David, > > I disagree. If you use jdk logging you require anyone using the > library to also use jdk logging. What makes you think that? > If you use slf4j (or commons-logging) > you require them put an slf4j implementation on their classpath which > delegates to the logging implementation they use for everything else. > > I don't want to configure jdk logging and juli and log4j and logkit > and nlog4j and slf4j in order to use assorted libraries, I want to > configure log4j and then tell everything else to use log4j. This is > what slf4j does. It is also possible to make JDK logging do this. Granted you have to set one system property and include a JAR. If, on the other hand, you were already using JDK logging, you don't have to do anything at all. The difference with slf4j is that you always must have slf4j to make it work. > > -Brian > > > On Dec 11, 2007, at 11:05 AM, David M. Lloyd wrote: > > > 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 >
