src/xdocs/index.xml - logging-log4j1 - Git at Google

 <?xml version="1.0"?>
 <document>

   <properties>
     <author email="ceki@apache.org">Ceki Gulcu</author>
     <title>Introduction</title>
   </properties>

   <meta name="keywords" content="java, logging, tracing, component, framework, API, log4j"/>


 <body>
     <section name="Introduction">

       <p>Inserting log statements into your code is a low-tech method
 	for debugging it.  It may also be the only way because
 	debuggers are not always available or applicable.  This is
 	often the case for distributed applications.</p>

       <p>On the other hand, some people argue that log statements
 	pollute source code and decrease legibility. (We believe that
 	the contrary is true).  In the Java language where a
 	preprocessor is not available, log statements increase the
 	size of the code and reduce its speed, even when logging is
 	turned off.  Given that a reasonably sized application may
 	contain thousands of log statements, speed is of particular
 	importance.</p>


       <p>With log4j it is possible to enable logging at runtime
 	without modifying the application binary. The log4j package is
 	designed so that these statements can remain in shipped code
 	without incurring a heavy performance cost. Logging behavior
 	can be controlled by editing a configuration file, without
 	touching the application binary.</p>

       <p>Logging equips the developer with <i>detailed context</i> for
 	application failures. On the other hand, testing provides
 	quality assurance and confidence in the application. Logging
 	and testing should not be confused. They are
 	complementary. When logging is wisely used, it can prove to be
 	an essential tool.</p>

       <p>One of the distinctive features of log4j is the notion of
 	<i>inheritance</i> in loggers. Using a logger
 	<em>hierarchy</em> it is possible to control which log
 	statements are output at arbitrarily fine granularity but also
 	great ease. This helps reduce the volume of logged output and
 	minimize the cost of logging.</p>

       <p>The target of the log output can be a file, an
 	<code>OutputStream</code>, a <code>java.io.Writer</code>, a
 	remote log4j server, a remote Unix Syslog daemon, or even a NT
 	Event logger among many other output targets.</p>

       <p>On an AMD Duron clocked at 800Mhz running JDK 1.3.1, it costs
 	about 5 nanoseconds to determine if a logging statement should
 	be logged or not. Actual logging is also quite fast, ranging
 	from 21 microseconds microseconds using the SimpleLayout, 37
 	microseconds using the TTCCLayout.  The performance of the
 	PatternLayout is almost as good as the dedicated layouts,
 	except that it is much more flexible.</p>

       <p>The package is being constantly improved thanks to input from
 	users and code contributed by authors in the community.
       </p>

     </section>
   </body>
 </document>
	<?xml version="1.0"?>
	<document>

	<properties>
	<author email="ceki@apache.org">Ceki Gulcu</author>
	<title>Introduction</title>
	</properties>

	<meta name="keywords" content="java, logging, tracing, component, framework, API, log4j"/>


	<body>
	<section name="Introduction">

	<p>Inserting log statements into your code is a low-tech method
	for debugging it. It may also be the only way because
	debuggers are not always available or applicable. This is
	often the case for distributed applications.</p>

	<p>On the other hand, some people argue that log statements
	pollute source code and decrease legibility. (We believe that
	the contrary is true). In the Java language where a
	preprocessor is not available, log statements increase the
	size of the code and reduce its speed, even when logging is
	turned off. Given that a reasonably sized application may
	contain thousands of log statements, speed is of particular
	importance.</p>


	<p>With log4j it is possible to enable logging at runtime
	without modifying the application binary. The log4j package is
	designed so that these statements can remain in shipped code
	without incurring a heavy performance cost. Logging behavior
	can be controlled by editing a configuration file, without
	touching the application binary.</p>

	<p>Logging equips the developer with <i>detailed context</i> for
	application failures. On the other hand, testing provides
	quality assurance and confidence in the application. Logging
	and testing should not be confused. They are
	complementary. When logging is wisely used, it can prove to be
	an essential tool.</p>

	<p>One of the distinctive features of log4j is the notion of
	<i>inheritance</i> in loggers. Using a logger
	<em>hierarchy</em> it is possible to control which log
	statements are output at arbitrarily fine granularity but also
	great ease. This helps reduce the volume of logged output and
	minimize the cost of logging.</p>

	<p>The target of the log output can be a file, an
	<code>OutputStream</code>, a <code>java.io.Writer</code>, a
	remote log4j server, a remote Unix Syslog daemon, or even a NT
	Event logger among many other output targets.</p>

	<p>On an AMD Duron clocked at 800Mhz running JDK 1.3.1, it costs
	about 5 nanoseconds to determine if a logging statement should
	be logged or not. Actual logging is also quite fast, ranging
	from 21 microseconds microseconds using the SimpleLayout, 37
	microseconds using the TTCCLayout. The performance of the
	PatternLayout is almost as good as the dedicated layouts,
	except that it is much more flexible.</p>

	<p>The package is being constantly improved thanks to input from
	users and code contributed by authors in the community.
	</p>

	</section>
	</body>
	</document>