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 [email protected] 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 [email protected] http://slf4j.org/mailman/listinfo/dev
-- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ _______________________________________________ dev mailing list [email protected] http://slf4j.org/mailman/listinfo/dev
