rgoers/src/site/xdoc/manual/index.xml - logging-log4j1 - Git at Google

 <?xml version="1.0"?>
 <!--
     Licensed to the Apache Software Foundation (ASF) under one or more
     contributor license agreements.  See the NOTICE file distributed with
     this work for additional information regarding copyright ownership.
     The ASF licenses this file to You under the Apache License, Version 2.0
     (the "License"); you may not use this file except in compliance with
     the License.  You may obtain a copy of the License at

          http://www.apache.org/licenses/LICENSE-2.0

     Unless required by applicable law or agreed to in writing, software
     distributed under the License is distributed on an "AS IS" BASIS,
     WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
     See the License for the specific language governing permissions and
     limitations under the License.
 -->

 <document>
     <properties>
         <title>Overview</title>
         <author email="rgoers@apache.org">Ralph Goers</author>
     </properties>

     <body>
       <section name="Welcome to Log4J 2.0!">
         <subsection name="Introduction">
           <p>Almost every large application includes its own logging or tracing
           API. In conformance with this rule, the E.U.  <a
           href="http://www.semper.org">SEMPER</a> project decided to write its
           own tracing API. This was in early 1996. After countless enhancements,
           several incarnations and much work that API has evolved to become
           log4j, a popular logging package for Java. The package is distributed
           under the <a href="../LICENSE">Apache Software License</a>, a
           fully-fledged open source license certified by the <a
           href="http://www.opensource.org">open source</a> initiative. The
           latest log4j version, including full-source code, class files and
           documentation can be found at <a
           href="http://logging.apache.org/log4j/2.0/index.html"><b>http://logging.apache.org/log4j/2.0/index.html</b></a>.
           </p>

           <p>Inserting log statements into 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 usually the case for
           multithreaded applications and distributed applications at large.</p>

           <p>Experience indicates that logging was an important component of the
           development cycle. It offeres several advantages. It provides precise
           <em>context</em> about a run of the application. Once inserted into
           the code, the generation of logging output requires no human
           intervention.  Moreover, log output can be saved in persistent medium
           to be studied at a later time. In addition to its use in the
           development cycle, a sufficiently rich logging package can also be
           viewed as an auditing tool.</p>

           <p>As Brian W. Kernighan and Rob Pike put it in their truly excellent
           book <i>"The Practice of Programming"</i>
           <pre>
             As personal choice, we tend not to use debuggers beyond getting a
             stack trace or the value of a variable or two. One reason is that it
             is easy to get lost in details of complicated data structures and
             control flow; we find stepping through a program less productive
             than thinking harder and adding output statements and self-checking
             code at critical places. Clicking over statements takes longer than
             scanning the output of judiciously-placed displays. It takes less
             time to decide where to put print statements than to single-step to
             the critical section of code, even assuming we know where that
             is. More important, debugging statements stay with the program;
             debugging sessions are transient.
           </pre></p>

           <p>Logging does have its drawbacks. It can slow down an
           application. If too verbose, it can cause scrolling blindness. To
           alleviate these concerns, log4j is designed to be reliable, fast and
           extensible. Since logging is rarely the main focus of an application,
           the log4j API strives to be simple to understand and to use.</p>
         </subsection>
         <subsection name="Log4j 2.0">
           Log4j 1.x has been widely adopted and used in many applications. However,
           through the years development on it has slowed down. It has become more
           difficult to maintain due to its need to be compliant with very old versions
           of Java.  Its alternative, SLF4J/Logback made many needed improvements to the
           framework. So why bother with Log4j 2.0? Here are a few of the reasons.
           <ol>
             <li>Log4j 2.0 is designed to be usable as an audit logging framework. Both Log4j
               1.x and Logback will lose events while reconfiguring. Log4j 2.0 will not. in
               Logback exceptions in Appenders are never visible to the application. In
               Log4j 2.0 Appenders can be configured to allow the exception to percolate
               to the application</li>
             <li>Log4j 2.0 uses a Plugin system that makes it extremely easy to extend the
               framework by adding new Appenders, Filters, Layouts, Lookups,
               and Pattern Converters without requiring any changes to Log4j.</li>
             <li>The performance of Log4j 2.0 is similar to that of Logback. It is slightly
               slower in some tests and faster in others.</li>
             <li>Due to the Plugin system configuration is simpler. Entries in the configuration
               do not require a class name to be specified.</li>
             <li>Support for Message objects. Messages allow support for interesting and
               complex constructs to be passed through the logging system and be efficiently
               manipulated. Users are free to create their own Message types and write custom
               Layouts, Filters and Lookups to manipulate them.</li>
             <li>Log4j 1.x supports Filters on Appenders. Logback added TurboFilters to allow
               filtering of events before they are processed by a Logger. Log4j 2.0 supports
               Filters that can be configured to process events before they are handled by
               a Logger, as they are processed by a Logger or on an Appender.</li>
             <li>Many Logback Appenders do not accept a Layout and will only send data in a
               fixed format. Most Log4j 2.0 Appenders accept a Layout, allowing the data to
               be transported in any format desired.</li>
             <li>Layouts in Log4j 1.x and Logback return a String. This resulted in the problems
               discussed at <a href="http://logback.qos.ch/manual/encoders.html">Logback Encoders</a>.
               Log4j 2.0 takes the simpler approach that Layouts always return a byte array. This has
               the advantage that it means they can be used in virtually any Appender, not just
               the ones that write to an OutputStream.</li>
             <li>The Syslog Appender supports both TCP and UDP as well as support for the BSD syslog
               and the <a href="http://tools.ietf.org/html/rfc5424">RFC 5424</a> formats.</li>
             <li>Log4j 2.0 takes advantage of Java 5 concurrency support and performs locking
               at the lowest level possible. Log4j 1.x has known deadlock issues. Many of these
               are fixed in Logback but many Logback classes still require synchronization at
               a fairly high level.</li>
             <li>It is an Apache Software Foundation project following the community and support
               model used by all ASF projects. If you want to contribute or gain the right to
               commit changes just follow the path outlined at
               <a href="http://jakarta.apache.org/site/contributing.html">Contributing</a></li>
           </ol>
         </subsection>
       </section>
     </body>
 </document>
	<?xml version="1.0"?>
	<!--
	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	The ASF licenses this file to You under the Apache License, Version 2.0
	(the "License"); you may not use this file except in compliance with
	the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->

	<document>
	<properties>
	<title>Overview</title>
	<author email="rgoers@apache.org">Ralph Goers</author>
	</properties>

	<body>
	<section name="Welcome to Log4J 2.0!">
	<subsection name="Introduction">
	<p>Almost every large application includes its own logging or tracing
	API. In conformance with this rule, the E.U. <a
	href="http://www.semper.org">SEMPER</a> project decided to write its
	own tracing API. This was in early 1996. After countless enhancements,
	several incarnations and much work that API has evolved to become
	log4j, a popular logging package for Java. The package is distributed
	under the <a href="../LICENSE">Apache Software License</a>, a
	fully-fledged open source license certified by the <a
	href="http://www.opensource.org">open source</a> initiative. The
	latest log4j version, including full-source code, class files and
	documentation can be found at <a
	href="http://logging.apache.org/log4j/2.0/index.html"><b>http://logging.apache.org/log4j/2.0/index.html</b></a>.
	</p>

	<p>Inserting log statements into 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 usually the case for
	multithreaded applications and distributed applications at large.</p>

	<p>Experience indicates that logging was an important component of the
	development cycle. It offeres several advantages. It provides precise
	<em>context</em> about a run of the application. Once inserted into
	the code, the generation of logging output requires no human
	intervention. Moreover, log output can be saved in persistent medium
	to be studied at a later time. In addition to its use in the
	development cycle, a sufficiently rich logging package can also be
	viewed as an auditing tool.</p>

	<p>As Brian W. Kernighan and Rob Pike put it in their truly excellent
	book <i>"The Practice of Programming"</i>
	<pre>
	As personal choice, we tend not to use debuggers beyond getting a
	stack trace or the value of a variable or two. One reason is that it
	is easy to get lost in details of complicated data structures and
	control flow; we find stepping through a program less productive
	than thinking harder and adding output statements and self-checking
	code at critical places. Clicking over statements takes longer than
	scanning the output of judiciously-placed displays. It takes less
	time to decide where to put print statements than to single-step to
	the critical section of code, even assuming we know where that
	is. More important, debugging statements stay with the program;
	debugging sessions are transient.
	</pre></p>

	<p>Logging does have its drawbacks. It can slow down an
	application. If too verbose, it can cause scrolling blindness. To
	alleviate these concerns, log4j is designed to be reliable, fast and
	extensible. Since logging is rarely the main focus of an application,
	the log4j API strives to be simple to understand and to use.</p>
	</subsection>
	<subsection name="Log4j 2.0">
	Log4j 1.x has been widely adopted and used in many applications. However,
	through the years development on it has slowed down. It has become more
	difficult to maintain due to its need to be compliant with very old versions
	of Java. Its alternative, SLF4J/Logback made many needed improvements to the
	framework. So why bother with Log4j 2.0? Here are a few of the reasons.
	<ol>
	<li>Log4j 2.0 is designed to be usable as an audit logging framework. Both Log4j
	1.x and Logback will lose events while reconfiguring. Log4j 2.0 will not. in
	Logback exceptions in Appenders are never visible to the application. In
	Log4j 2.0 Appenders can be configured to allow the exception to percolate
	to the application</li>
	<li>Log4j 2.0 uses a Plugin system that makes it extremely easy to extend the
	framework by adding new Appenders, Filters, Layouts, Lookups,
	and Pattern Converters without requiring any changes to Log4j.</li>
	<li>The performance of Log4j 2.0 is similar to that of Logback. It is slightly
	slower in some tests and faster in others.</li>
	<li>Due to the Plugin system configuration is simpler. Entries in the configuration
	do not require a class name to be specified.</li>
	<li>Support for Message objects. Messages allow support for interesting and
	complex constructs to be passed through the logging system and be efficiently
	manipulated. Users are free to create their own Message types and write custom
	Layouts, Filters and Lookups to manipulate them.</li>
	<li>Log4j 1.x supports Filters on Appenders. Logback added TurboFilters to allow
	filtering of events before they are processed by a Logger. Log4j 2.0 supports
	Filters that can be configured to process events before they are handled by
	a Logger, as they are processed by a Logger or on an Appender.</li>
	<li>Many Logback Appenders do not accept a Layout and will only send data in a
	fixed format. Most Log4j 2.0 Appenders accept a Layout, allowing the data to
	be transported in any format desired.</li>
	<li>Layouts in Log4j 1.x and Logback return a String. This resulted in the problems
	discussed at <a href="http://logback.qos.ch/manual/encoders.html">Logback Encoders</a>.
	Log4j 2.0 takes the simpler approach that Layouts always return a byte array. This has
	the advantage that it means they can be used in virtually any Appender, not just
	the ones that write to an OutputStream.</li>
	<li>The Syslog Appender supports both TCP and UDP as well as support for the BSD syslog
	and the <a href="http://tools.ietf.org/html/rfc5424">RFC 5424</a> formats.</li>
	<li>Log4j 2.0 takes advantage of Java 5 concurrency support and performs locking
	at the lowest level possible. Log4j 1.x has known deadlock issues. Many of these
	are fixed in Logback but many Logback classes still require synchronization at
	a fairly high level.</li>
	<li>It is an Apache Software Foundation project following the community and support
	model used by all ASF projects. If you want to contribute or gain the right to
	commit changes just follow the path outlined at
	<a href="http://jakarta.apache.org/site/contributing.html">Contributing</a></li>
	</ol>
	</subsection>
	</section>
	</body>
	</document>