mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David M. Lloyd" <david.ll...@redhat.com>
Subject Revisiting logging in MINA 2.0
Date Tue, 11 Dec 2007 19:05:55 GMT
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

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.



View raw message