20091105 (logging)

log4j

The inherited level for a given logger C, is equal to the first non-null level in the logger hierarchy, starting at C and proceeding upwards in the hierarchy towards the root logger.

The output of a log statement of logger C will go to all the appenders in C and its ancestors. This is the meaning of the term "appender additivity".
However, if an ancestor of logger C, say P, has the additivity flag set to false, then C's output will be directed to all the appenders in C and it's ancestors upto and including P but not the appenders in any of the ancestors of P.
Loggers have their additivity flag set to true by default.

The PatternLayout, part of the standard log4j distribution, lets the user specify the output format according to conversion patterns similar to the C language printf function.

BasicConfigurator

PropertyConfigurator

DOMConfigurator

static inializer of the Logger class
The exact default initialization algorithm is defined as follows:
Setting the log4j.defaultInitOverride system property to any other value then "false" will cause log4j to skip the default initialization procedure (this procedure).
Set the resource string variable to the value of the log4j.configuration system property. The preferred way to specify the default initialization file is through the log4j.configuration system property. In case the system property log4j.configuration is not defined, then set the string variable resource to its default value "log4j.properties".
Attempt to convert the resource variable to a URL.
If the resource variable cannot be converted to a URL, for example due to a MalformedURLException, then search for the resource from the classpath by calling org.apache.log4j.helpers.Loader.getResource(resource, Logger.class) which returns a URL. Note that the string "log4j.properties" constitutes a malformed URL. See Loader.getResource(java.lang.String) for the list of searched locations.
If no URL could not be found, abort default initialization. Otherwise, configure log4j from the URL. The PropertyConfigurator will be used to parse the URL to configure log4j unless the URL ends with the ".xml" extension, in which case the DOMConfigurator will be used. You can optionaly specify a custom configurator. The value of the log4j.configuratorClass system property is taken as the fully qualified class name of your custom configurator. The custom configurator you specify must implement the Configurator interface.

To uniquely stamp each request, the user pushes contextual information into the NDC, the abbreviation of Nested Diagnostic Context.
Use org.apache.log4j.NDC

对于log4j，priority level是由上至下继承的，但是log的propagate，包括appender却是由下至上的

properties config的前缀、层次
所有都以log4j开头
log4j.rootLogger/log4j.logger.xxx = [level], [appender]
log4j.appender.xxx = [appender class]
log4j.appender.xxx.layout = [layout class]
log4j.appender.xxx.yyy = [appender property value]

slf

All SLF4J adapters support formated log messages with significantly improved performace results.
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

The SLF4J distribution ships with several jar files slf4j-nop.jar, slf4j-simple.jar, slf4j-log4j12.jar, slf4j-log4j13.jar, slf4j-jdk14.jar and slf4j-jcl.jar. Each of these jar files is hardwired at compile-time to use just one implementation.
As noted earlier, SLF4J does not rely on any special class loader machinery. Every variant of slf4j-<impl>.jar is statically hardwired at compile time to use one and only specific implementation. Thus, SLF4J suffers from none of the class loader problems observed when using JCL.

jcl104-over-slf4j.jar
To ease migration to SLF4J from JCL, recent SLF4J distributions include the jar file jcl104-over-slf4j.jar. This jar file is intended as a drop-in replacement for JCL version 1.0.4. It implements the public API of JCL but using SLF4J underneath, hence the name "JCL over SLF4J."

slf4j-jcl.jar
Some of our users after having switched to SLF4J API realize that in some contexts the use of JCL is mandatory and their use of SLF4J can be a problem.
The JCL binding will delegate all logging calls made through SLF4J API to JCL.

jcl104-over-slf4j.jar should not be confused with slf4j-jcl.jar
Please note that jcl104-over-slf4j.jar and slf4j-jcl.jar cannot be deployed at the same time. The former jar file will cause JCL to delegate the choice of the logging system to SLF4J and the latter jar file will cause SLF4J to delegate the choice of the logging system to JCL, resulting in an infinite loop.