On Tue, 11 Dec 2007 13:06:43 -0500 "Jason T. Greene"
<jason.greene(a)redhat.com> wrote:
Tim Fox wrote:
> I think what we really need here is to write another "meta" logging
> framework for our projects to use, and that can just delegate to slf4j,
> log4j, java.util logging etc ;)
We do, it's jboss-commons-logging. :)
Tim was being ironic I think. Let me answer this in a different way -
jboss commons logging solves the problem within the container just fine.
The container can now (presumably [I haven't tried it yet!]) allow the
user to configure it to use the JDK appender system, or log4j. And
within the container, you've got a much nicer API than either log4j or
JDK logging provides.
But what I'm really referring two are other libraries that require
logging, but may or may not run within a container (ours or others). In
this case, using *any* framework (even meta frameworks like
jboss-commons-logging, slf4j, and apache commons-logging) just causes
more problems for the user, who then needs JARs for every framework and
meta-framework around.
The key advantage to JDK logging is that it's in the JDK. This is
actually it's only advantage IMO - but it is the critical advantage
that makes the difference. If you want logging in your library, but
you don't want to require a JAR for it, you really have no other option.
Tim Fox wrote:
Seriously though, I echo many of David concerns.
We are in a similar position as David (and Bela) with MINA - I don't
really want to pull in a slf4j dependency. Although I understand Trustin
has some difficulty in removing this due to the way Apache democracies
work :(
Well, I've sent a heartfelt appeal to the MINA list, so we'll see what
happens.
- DML