[slf4j-dev] Common Logging API

Joerg Hohwiller joerg at j-hohwiller.de
Thu Aug 4 21:32:10 CEST 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

I am new to slf4j.
Actually I startet a thread called "[logging] proposal"
on commons-dev at jakarta.apache.org to discuss about an API extension
for commons-logging.
My major goal or vision about all of this is that we -the entire java
community- will have one API for a Logger. Basically I think that
commons logging is a good approach towards this but still after having
commons logging there are still a lot of projects inventing their own
logger API. Searching for the reason for that by discussing
with the people of those projects on their mailing lists gave me the
conclusion that the only point is that org.apache.commons.logging.Log is
missing an important feature: A method to create a child logger:
getChildLogger(String).
I am also one of these IoC Container guys thesedays and
so my suggestion was to add another interface called
org.apache.commons.logging.Logger that extends Log and adds the methods:

String getName()
Logger getChildLogger(String)

I posted a list of various open-source projects that invented thier own
logger interface that is pretty much the same as commons logging's Log
but has these two additional methods (maybe they have a slightly
different signature).

It seems that slf4j is different from those IoC frameworks and more like
  commons logging in the way that you also focus on the logging itself
and intend to be widely used for logging - if I guessed this right.

Now cross-posting on different mailing lists is not to easy. So we will
see how we will get a long. But I would love to see your points about
the "true" logging API. Unfortunately we do not have Smalltalk here but
JAVA so in the end we need an Interface in a concrete classpath
namespace. But hopefully a come together would be possible somehow.
I do not expect it to happen that the classpath will be
java.util.logging2.Logger :)
For me org.apache.commons.logging.Logger would be good enough and
since org.apache.commons.logging.Log is already widely used
those projects using it could still be going on without any worries.

So let me know:
Would org.apache.commons.logging.Logger be acceptable or would the
JAVA classpath thing be a political issue for you that disallows
this option?

Actually I love your idea of making the logger (log4j) directly
implement the "true" logging API so no bridge is needed and no
performance is wasted.

What do you think of the idea? What are your expectations about the
"true" logging API?

I do integrate various open-source projects both in my own open-source
project and in my business. And I can tell you that it is an insane mess
that you end up with 10-20 logging and metalogging JARs in your classpath!!!
Do we really want this???
Couldnt we come together - make peace not war :))

http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/Log.html
http://www.slf4j.org/api/org/slf4j/Logger.html
http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html
http://excalibur.apache.org/apidocs/org/apache/avalon/framework/logger/Logger.html
http://svn.plexus.codehaus.org/trunk/plexus-containers/plexus-container-default/src/main/java/org/codehaus/plexus/logging/Logger.java
http://dpml.net/api/dpml/transit/3000/net/dpml/transit/model/Logger.html
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/catalina/docs/api/org/apache/catalina/Logger.html
http://docs.fluxcorp.com/javadoc/flux/logging/Logger.html
http://e-docs.bea.com/workshop/docs81/doc/en/core/index.html
http://my.unidata.ucar.edu/content/software/netcdf/java/docs/ucar/util/Logger.html
http://livedocs.macromedia.com/jrun/4/javadocs/jrunx/logger/Logger.html
...

just to meantion a few of them.

PLEAS make up your mind.

Thank you!

Take care
  Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC8m06mPuec2Dcv/8RAilgAJ9j+slYu9ZH5RTVfAF2biw+YVWv+ACeMotw
23J8totz8gytS0raWJGnFG8=
=UrFD
-----END PGP SIGNATURE-----



More information about the slf4j-dev mailing list