David,
I disagree. If you use jdk logging you require anyone using the
library to also use jdk logging. 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.
-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
