[slf4j-dev] Common Logging API

Fri Aug 5 13:44:14 CEST 2005

By convention, I use labels [N] a document references. The list of
references can be found at the end of this message.

Hello Joerg,

The jury is still out on the question of the ideal logging API. I do
not expect them (the jury) to make up their mind anytime soon. :-)

Niclas Hedman has been gently trying to convince us to add a
getChildLogger() method in the Logger interface [1] for quite some
time now. It is becoming increasingly clear that IoC frameworks yearn
for such functionality.

Version 1.0beta5 of SLF4J (not yet released) makes several important
enhancements to the Logger interface. You can find the javadocs for
beta5 at [2]. Please note that these javadocs a quite different than
the publicly advertised javadocs on the "Documentation" page [3].

If I understand correctly, you would like to see the following two
methods added to the org.slf4j.Logger interface:

   String getName()
   Logger getChildLogger(String)

The first method, namely getName(), sounds most legitimate. If the
developer retrieves loggers by name, it is only natural for those
loggers to have a name. The only exception is the NOPLogger
singleton. If SLF4J is bound to the NOP implementation, the logger
factory will always hand the user the same NOPLogger instance,
regardless of the name of the logger requested by her.

Thus, it seems quite reasonable to add the getName() method, with the
caveat that the name you get may be different than the name you asked
for. :-)

Your second request is both interesting and more problematic. You are
essentially asking for org.slf4j.Logger instances to have
manufacturing capability. As you are probably aware, manufacturing the
correct Logger instance of the correct type in every application
context is a very difficult problem. This is another area where IoC
frameworks lend a helping hand. If possible, I think it wiser for
SLF4J to decouple logging capability from manufacturing capability.

As you can see in SLF4J 1.0-beta5 [2], there is a clear separation
between org.slf4j.Logger and org.slf4j.ILoggerFactory
interfaces. Instances of the latter interface build instances of the
former. The LoggerFactory class wraps a particular instance of
ILoggerFactory (normally bound at compile time).

Wouldn't it be possible for your IoC framework to inject
ILoggerFactory instances instead of Logger instances to the component
being configured? More concretely, Niclas' MyClass/MyOtherClass
example in [1] can be modified to use the ILoggerFactory approach [4].

Do you see any disadvantages to the ILoggerFactory injection approach?
Alternatively, do you see any advantages?

In any case, I would like to thank you for taking the time to express
the requirements as seen from the point of view of a IOC developer.
Your input is most appreciated.

Cheers,

[1] http://www.slf4j.org/pipermail/dev/2005-May/000049.html
[2] http://www.slf4j.org/api-1.0-beta5/
[3] http://www.slf4j.org/docs.html
[4] http://www.slf4j.org/pipermail/dev/2005-July/000212.html

At 09:32 PM 8/4/2005, Joerg Hohwiller wrote:
>-----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-----
>_______________________________________________
>dev mailing list
>dev at slf4j.org
>http://slf4j.org/mailman/listinfo/dev

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/