ceki 01/09/08 10:57:38
Modified: src/docbook glossary.xml intro.xml manual.xml
Added: src/docbook architecture.xml configuration.xml
Log:
More docs
Revision Changes Path
1.2 +7 -3 jakarta-log4j/src/docbook/glossary.xml
Index: glossary.xml
===================================================================
RCS file: /home/cvs/jakarta-log4j/src/docbook/glossary.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- glossary.xml 2001/09/07 17:36:20 1.1
+++ glossary.xml 2001/09/08 17:57:38 1.2
@@ -9,9 +9,13 @@
<glossentry id="gloss-printingMethods">
<glossterm>Logger Printing Methods</glossterm>
<glossdef>
- <para>Method such as debug, info, warn and error and fatal that
- can be invoked on a logger in order to log messsages.</para>
- <glossseealso otherterm="sgml">SGML</glossseealso>
+ <para>Methods defined in the <ulink
+ url="../api/org/apache/log4j/Logger.html">Logger</ulink>
+ class such as such as <function>debug</function>,
+ <function>info</function>, <function>warn</function>,
+ <function>error</function>, <function>fatal</function> and
+ <function>log</function>.
+ </para>
</glossdef>
</glossentry>
1.4 +103 -29 jakarta-log4j/src/docbook/intro.xml
Index: intro.xml
===================================================================
RCS file: /home/cvs/jakarta-log4j/src/docbook/intro.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- intro.xml 2001/09/08 15:46:14 1.3
+++ intro.xml 2001/09/08 17:57:38 1.4
@@ -44,22 +44,23 @@
<para>As Brian W. Kernigan and Rob Pike put it in their truly
excellent book <emphasis>"The Practice of Programming"</emphasis>
</para>
-
+
<blockquote>
- 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;
+ <para>
+ 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.
+ </para>
</blockquote>
-
-
+
<para>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 fast and flexible. Since logging is
@@ -106,15 +107,15 @@
<para>Please also see <xref linkend="faq-threadSafe"/>.</para>
- <example>
+ <example id="MyApp1">
<title>First attempt</title>
<programlisting linenumbering="numbered">
- package my.com;
+ package chapter1;
import org.apache.log4j.Logger;
- public class MyApp {
- <emphasis role="strong">static</emphasis> final Logger logger =
Logger.getLogger(MyApp.class);
+ public class MyApp1 {
+ static final Logger logger = Logger.getLogger(MyApp1.class.getName());
static public void main(String[] args) {
logger.debug("Hello world.");
@@ -124,22 +125,95 @@
</example>
<caution>
- Running this example will not produce any logging output but the
- following warning.
- <computeroutput>
-
- <computeroutput>
+ <para>
+ Running this example will not produce any logging output but the
+ following warning.
+ <literallayout>
+ <computeroutput>
+log4j:ERROR No appenders could be found for logger (chapter1.MyApp1).
+log4j:ERROR Please initialize the log4j system properly.
+ </computeroutput>
+ </literallayout>
+ </para>
</caution>
+ <para>Log4j is complaining because we have not configured
+ it. There are many different ways for configuring log4j. The
+ simplest way is by calling the
+ <function>BasicConfigurator.configure()</function> method.
+ </para>
+
+ <example id="MyApp2">
+ <title>Second and successful attempt</title>
+ <programlisting linenumbering="numbered">
+ package chapter1;
+
+ import org.apache.log4j.Logger;
+ import org.apache.log4j.BasicConfigurator;
+
+ public class MyApp2 {
+ static final Logger logger = Logger.getLogger(MyApp2.class.getName());
+
+ static public void main(String[] args) {
+ BasicConfigurator.configure();
+ logger.debug("Hello world.");
+ }
+ }
+ </programlisting>
+ </example>
<para>
- Using log4j in your own code is quite easy. First, you need to
- import <classname>org.apache.log4j.Logger</classname> class and
- then invoke the <methodname>Logger.getLogger</methodname> method
- to instantiate a Logger object. Subsequently, you can invoke one
- of the <link linkend="gloss-printingMethods">printing
- methods</link> of the logger, e.g. debug, to log your messages.
+ Running this example will produce the following output.
+ <literallayout>
+ <computeroutput>
+ 0 [main] DEBUG chapter1.MyApp2 - Hello world.
+ </computeroutput>
+ </literallayout>
</para>
-
+
+ <procedure>
+ <title>Using log4j</title>
+
+ <para>This is are the steps you must take in order to use log4j
+ in your applications.
+ </para>
+
+ <step performance="required">
+ <para>
+ Configure log4j for your environment. Log4j offers many
+ sophisticated means of configuration,
+ <function>BasicConfigurator.configure()</function> being the
+ simplest but also the least flexible. There is a whole
+ chapter dedicated to this topic. Please refer to <xref
+ linkend="chap-configuration"/> for more details.
+ </para>
+
+ <para>
+ <tip>
+ <para>
+ Log4j normally needs to be configured only once. Some
+ new users try to configure log4j in each and every
+ class. This is wrong and must be avoided.
+ </para>
+ </tip>
+ </para>
+ </step>
+
+ <step performance="required">
+ <para>In every class where you wish to perform logging,
+ instantiate a Logger object by invoking the
+ <function>Logger.getLogger</function> method and passing it
+ a string, usualy (but not necessarily) the fully qualified
+ name of the containing class. The logger object is usually
+ declared as a <varname>static final</varname>.
+ </para>
+ </step>
+
+ <step performance="required">
+ <para>Use this logger instance to log by invoking its <link
+ linkend="gloss-printingMethods">printing methods</link>.
+ </para>
+ </step>
+ </procedure>
</sect1>
</chapter>
1.4 +6 -40 jakarta-log4j/src/docbook/manual.xml
Index: manual.xml
===================================================================
RCS file: /home/cvs/jakarta-log4j/src/docbook/manual.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- manual.xml 2001/09/08 15:46:14 1.3
+++ manual.xml 2001/09/08 17:57:38 1.4
@@ -1,6 +1,8 @@
<?xml version='1.0'?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" [
<!ENTITY intro SYSTEM "intro.xml">
+<!ENTITY architecture SYSTEM "archiecture.xml">
+<!ENTITY conf SYSTEM "configuration.xml">
<!ENTITY glo SYSTEM "glossary.xml">
]>
@@ -42,6 +44,8 @@
&intro
+ &architecture
+
<chapter>
<title>Architecture</title>
<para></para>
@@ -68,48 +72,10 @@
</sect1>
- <sect1>
- <title>Performance</title>
- <para></para>
- </sect1>
-
- </chapter>
-
-
- <chapter>
- <title>Configuration</title>
-
- <sect1>
- <title>PropertyConfigurator</title>
- <para></para>
- </sect1>
-
- <sect1>
- <title>DOMConfigurator</title>
- <para></para>
- </sect1>
-
- <sect1>
- <title>Default configuration</title>
- <para></para>
- </sect1>
-
- <sect1>
- <title>Filters</title>
- <para></para>
- </sect1>
- <sect1>
- <title>Error handlers</title>
- <para></para>
- </sect1>
-
- <sect1>
- <title>Category Factories</title>
- <para></para>
- </sect1>
-
</chapter>
+
+ &conf
<chapter>
<title>Logging in servers and other Multithreaded environments</title>
1.1 jakarta-log4j/src/docbook/architecture.xml
Index: architecture.xml
===================================================================
<chapter>
<title>Logger, Appenders and Layouts</title>
<para>Log4j has three main components: <em>loggers</em>,
<em>appenders</em> and <em>layouts</em>. These three types of
components work together to enable developers to log messages
according to message type and priority, and to control at
runtime how these messages are formatted and where they are
reported.
</para>
<sect1>Logger hierarchy</sect1>
<para>The first and foremost advantage of any logging API over
plain <function>System.out.println</function> resides in its
ability to disable certain log statements while allowing others
to print unhindered. This capability assumes that the logging
space, that is, the space of all possible logging statements, is
categorized according to some developer-chosen criteria. </para>
<para>This observation had previously led us to choose
<emphasis>category</emphasis> as the central concept of the
package. However, since log4j version 1.2, <ulink
url="api/org/apache/log4j/Logger.html">Logger</ulink>
<classname>Logger</classname> class has replaced the
<classname>Category</classname> class.
<para>Loggers are named entities. Logger names are
case-sensitive and they follow the hierarchical naming rule:
</para>
<para>
<variablelist>
<varlistentry>
<term><emphasis rule="bold">Named Hierarchy Rule</emphasis></term>
<listitem>
<para>A category is said to be an
<emphasis>ancestor</emphasis> of another category if
its name followed by a dot is a prefix of the
<emphasis>descendant</emphasis> category name. A
category is said to be a <emphasis>parent</emphasis>
of a <emphasis>child</emphasis> category if there are
no ancestors between itself and the descendant
category.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</para>
<para>For example, the category named <code>"com.foo"</code> is a parent
of the category named <code>"com.foo.Bar"</code>. Similarly,
<code>"java"</code> is a parent of <code>"java.util"</code> and an
ancestor of <code>"java.util.Vector"</code>. This naming scheme
should be familiar to most developers.
<para>The root category resides at the top of the category hierarchy. It
is exceptional in two ways:
<ol>
<li> it always exists,
<li> it cannot be retrieved by name.
</ol>
<para>Invoking the class static <a
href="api/org/apache/log4j/Category.html#getRoot()">Category.getRoot</a>
method retrieves it. All other categories are instantiated and
retrieved with the class static <a
href="api/org/apache/log4j/Category.html#getRoot()">Category.getInstance</a>
method. This method takes the name of the desired category as a
parameter. Some of the basic methods in the Category class are listed
below.
<para><table>
<tr bgcolor="CCCCCC">
<td>
<pre>
package org.apache.log4j;
public <b>Category</b> class {
// Creation & retrieval methods:
public static Category getRoot();
public static Category getInstance(String name);
// printing methods:
public void debug(Object message);
public void info(Object message);
public void warn(Object message);
public void error(Object message);
// generic printing method:
public void log(Priority p, Object message);
}
</pre>
</td>
</table>
<para>Categories <emphasis>may</emphasis> be assigned priorities. The set of possible
priorities, that is
<a href="api/org/apache/log4j/Priority.html#DEBUG">DEBUG</a>,
<a href="api/org/apache/log4j/Priority.html#INFO">INFO</a>,
<a href="api/org/apache/log4j/Priority.html#WARN">WARN</a>,
<a href="api/org/apache/log4j/Priority.html#ERROR">ERROR</a> and
<a href="api/org/apache/log4j/Priority.html#FATAL">FATAL</a>
are defined in the <code><a
href="api/org/apache/log4j/Priority.html">org.apache.log4j.Priority</a></code>
class. Although we do not encourage you from doing so, you may define
your own priorities by sub-classing the <code>Priority</code> class. A
perhaps better approach is will be explained later on.
<para>If a given category is not assigned a priority, then it inherits
one from its closest ancestor with an assigned priority. More
formally:
<para>
<table bgcolor="#EEEE99">
<tr>
<td>
<dl>
<dt><b>Priority Inheritance</b>
<dd><para>The <emphasis>inherited priority</emphasis> for a given category
<i>C</i>, is equal to the first non-null priority in the category
hierarchy, starting at <i>C</i> and proceeding upwards in the
hierarchy towards the <code>root</code> category.
</dl>
</table>
<para>To ensure that all categories can eventually inherit a priority,
the root category always has an assigned priority.
<para>Below are four tables with various assigned priority values and the
resulting inherited priorities according to the above rule.
<para>
<table border="1" >
<tr><th>Category<br>name</th><th>Assigned<br>priority</th>
<th>Inherited<br>priority</th></tr>
<tr align=left><td>root</td> <td>Proot</td> <td>Proot</td></tr>
<tr align=left><td>X </td> <td>none</td> <td>Proot</td></tr>
<tr align=left><td>X.Y </td> <td>none</td> <td>Proot</td></tr>
<tr align=left><td>X.Y.Z</td> <td>none</td> <td>Proot</td></tr>
<caption align=bottom>Example 1</caption>
</table>
<para>In example 1 above, only the root category is assinged a
priority. This priority value, <code>Proot</code>, is inherited by the
other categories <code>X</code>, <code>X.Y</code> and
<code>X.Y.Z</code>.
<para>
<table border="1">
<tr><th>Category<br>name</th><th>Assigned<br>priority</th>
<th>Inherited<br>priority</th></tr>
<tr align=left><td>root</td> <td>Proot</td> <td>Proot</td></tr>
<tr align=left><td>X </td> <td>Px</td> <td>Px</td></tr>
<tr align=left><td>X.Y </td> <td>Pxy</td> <td>Pxy</td></tr>
<tr align=left><td>X.Y.Z</td> <td>Pxyz</td> <td>Pxyz</td></tr>
<caption align=bottom>Example 2</caption>
</table>
<para>In example 2, all categories have an assigned priority value. There
is no need for priority inheritence.
<para><table border="1">
<tr><th>Category<br>name</th><th>Assigned<br>priority</th>
<th>Inherited<br>priority</th></tr>
<tr align=left><td>root</td> <td>Proot</td> <td>Proot</td></tr>
<tr align=left><td>X </td> <td>Px</td> <td>Px</td></tr>
<tr align=left><td>X.Y </td> <td>none</td> <td>Px</td></tr>
<tr align=left><td>X.Y.Z</td> <td>Pxyz</td> <td>Pxyz</td></tr>
<caption align=bottom>Example 3</caption>
</table>
<para>In example 3, the categories <code>root</code>, <code>X</code> and
<code>X.Y.Z</code> are assigned the priorities <code>Proot</code>,
<code>Px</code> and <code>Pxyz</code> respectively. The category
<code>X.Y</code> inherits its priority value from its parent
<code>X</code>.
<table border=1>
<tr><th>Category<br>name</th><th>Assigned<br>priority</th>
<th>Inherited<br>priority</th></tr>
<tr align=left><td>root</td> <td>Proot</td> <td>Proot</td></tr>
<tr align=left><td>X </td> <td>Px</td> <td>Px</td></tr>
<tr align=left><td>X.Y </td> <td>none</td> <td>Px</td></tr>
<tr align=left><td>X.Y.Z</td> <td>none</td> <td>Px</td></tr>
<caption align=bottom>Example 4</caption>
</table>
<para>In example 4, the categories <code>root</code> and <code>X</code>
and are assigned the priorities <code>Proot</code> and <code>Px</code>
respectively. The categories <code>X.Y</code> and <code>X.Y.Z</code>
inherits their priority value from their nearest parent <code>X</code>
having an assigned priority..
<para>Logging requests are made by invoking one of the printing methods
of a category instance. These printing methods are
<code>
<a href="api/org/apache/log4j/Category.html#debug(java.lang.Object)">debug</a>,
<a href="api/org/apache/log4j/Category.html#info(java.lang.Object)">info</a>,
<a href="api/org/apache/log4j/Category.html#warn(java.lang.Object)">warn</a>,
<a href="api/org/apache/log4j/Category.html#error(java.lang.Object)">error</a>,
<a href="api/org/apache/log4j/Category.html#fatal(java.lang.Object)">fatal</a>
and <a href="api/org/apache/log4j/Category.html#log(org.apache.log4j.Priority,
java.lang.Object)">log</a></code>.
<para>By definition, the printing method determines the priority of a
logging request. For example, if <code>c</code> is a category
instance, then the statement <code>c.info("..")</code> is a logging
request of priority INFO.
<para>A logging request is said to be <emphasis>enabled</emphasis> if its priority is
higher than or equal to the priority of its category. Otherwise, the
request is said to be <emphasis>disabled</emphasis>. A category without an
assigned priority will inherit one from the hierarchy. This rule is
summarized below.
<para>
<a name="selectionRule"><table bgcolor="#EEEE99">
<tr>
<td>
<dl>
<dt><b>Basic Selection Rule</b>
<dd><para>A log request of priority <i>p</i> in a category with
inherited priority <i>q</i>, is enabled if <i> p >=
q</i>.
</dl>
</table>
<para>This rule is at the heart of log4j. It assumes that priorities are
ordered. For the standard priorities, we have <code>DEBUG < INFO
< WARN < ERROR < FATAL</code>.
<para>Here is an example of this rule.
<para><table bgcolor="CCCCCC">
<tr><td>
<pre>
// get a category instance named "com.foo"
Category cat = Category.getInstance(<strong>"com.foo"</strong>);
// Now set its priority. Normally you do not need to set the
// priority of a category progamitcally. This is usually done
// in configuration files.
<strong>cat</strong>.setPriority(<font
color="0000AA"><strong>Priority.INFO</strong></font>);
Category barcat = Category.getInstance(<strong>"com.foo.Bar"</strong>);
// This request is enabled, because <font
color="00AA00"><strong>WARN</strong></font> >= <font
color="0000AA"><strong>INFO</strong></font>.
cat.<font color="00AA00"><strong>warn</strong></font>("Low fuel level.");
// This request is disabled, because <font
color="00AA00"><strong>DEBUG</strong></font> < <font
color="0000AA"><strong>INFO</strong></font>.
cat.<font color="00AA00"><strong>debug</strong></font>("Starting search for
nearest gas station.");
// The category instance barcat, named "com.foo.Bar",
// will inherit its priority from the category named
// "com.foo" Thus, the following request is enabled
// because <font color="00AA00"><strong>INFO</strong></font> >= <font
color="0000AA"><strong>INFO</strong></font>.
barcat.<font color="00AA00"><strong>info</strong></font>("Located nearest gas
station.");
// This request is disabled, because <font
color="00AA00"><strong>DEBUG</strong></font> < <font
color="0000AA"><strong>INFO</strong></font>.
barcat.<font color="00AA00"><strong>debug</strong></font>("Exiting gas station
search");
</pre>
</table>
<para>Calling the <code>getInstance</code> method with the same name will
always return a reference to the exact same category object.
<para>For example, in
<table bgcolor="CCCCCC">
<tr><td>
<pre>
Categoty x = Category.getInstance("wombat");
Categoty y = Category.getInstance("wombat");</pre>
</td>
</table>
<code>x</code> and <code>y</code> refer to <emphasis>exactly</emphasis> the same
category object.
<para>Thus, it is possible to configure a category and then to retrieve
the same instance somewhere else in the code without passing around
references. In fundamental contradiction to biological parenthood,
where parents always preceed their children, log4j categories can be
created and configured in any order. In particular, a "parent"
category will find and link to its descendants even if it is
instantiated after them.
<para>Configuration of the log4j environment is typically done at
application initialization. The preferred way is by reading a
configuration file. This approach will be discussed shortly.
<para>Log4j makes it easy to name categories by <emphasis>software
component</emphasis>. This can be accomplished by statically instantiating
a category in each class, with the category name equal to the fully
qualified name of the class. This is a useful and straightforward
method of defining categories. As the log output bears the name of the
generating category, this naming strategy makes it easy to identify
the origin of a log message. However, this is only one possible,
albeit common, strategy for naming categories. Log4j does not restrict
the possible set of categories. The developer is free to name the
categories as desired.
<para>Nevertheless, naming categories after the class where they are
located seems to be the best strategy known so far.
<h2>Appenders and Layouts</h2>
<para>The ability to selectively enable or disable logging requests based
on their category is only part of the picture. Log4j allows logging
requests to print to multiple destinations. In log4j speak, an output
destination is called an <emphasis>appender</emphasis>. Currently, appenders exist
for the <a href="api/org/apache/log4j/ConsoleAppender.html">console</a>, <a
href="api/org/apache/log4j/FileAppender.html">files</a>, GUI
components, <a
href="api/org/apache/log4j/net/SocketAppender.html">remote socket</a>
servers, <a
href="api/org/apache/log4j/net/JMSAppender.html">JMS</a>,
<a href="api/org/apache/log4j/nt/NTEventLogAppender.html"> NT
Event Loggers</a>, and remote UNIX <a
href="api/org/apache/log4j/net/SyslogAppender.html">Syslog</a>
daemons. It is also possible to log <a
href="api/org/apache/log4j/AsyncAppender.html">asynchronously</a>.
<para>More than one appender can be attached to a category.
<para>The <a
href="api/org/apache/log4j/Category.html#addAppender(org.apache.log4j.Appender)">addAppender</a>
method adds an appender to a given category.
<b>Each enabled logging
request for a given category will be forwarded to all the appenders in
that category as well as the appenders higher in the hierarchy.</b> In
other words, appenders are inherited additively from the category
hierarchy. For example, if a console appender is added to the root
category, then all enabled logging requests will at least print on the
console. If in addition a file appender is added to a category, say
<emphasis>C</emphasis>, then enabled logging requests for <emphasis>C</emphasis> and
<emphasis>C</emphasis>'s children will print on a file <emphasis>and</emphasis> on
the
console. It is possible to override this default behavior so that
appender accumulation is no longer additive by <a
href="api/org/apache/log4j/Category.html#setAdditivity(boolean)">setting
the additivity flag</a> to <code>false</code>.
<para>The rules governing appender additivity are summarized below.
<para>
<a name="additivity"><table bgcolor="#EEEE99">
<tr>
<td>
<dl>
<dt><b>Appender Additivity</b>
<dd><para>The output of a log statement of category <i>C</i> will
go to all the appenders in <i>C</i> and its ancestors. This is
the meaning of the term "appender additivity".
<para>However, if an ancestor of category <i>C</i>, say <i>P</i>,
has the additivity flag set to <code>false</code>, then
<i>C</i>'s output will be directed to all the appenders in
<i>C</i> and it's ancestors upto and including <i>P</i> but
not the appenders in any of the ancestors of <i>P</i>.
<para>Categories have their additivity flag set to
<code>true</code> by default.
</dl>
</table>
<para>The table below shows an example:
<para><table align=center border=3 cellpadding=10>
<tr rowspan="2">
<th>Category<br>Name <th>Added<br>Appenders <th>Additivity<br>Flag <th>Output
Targets <th>Comment
<tr><td>root <td>A1 <td>not applicable <td>A1
<td>The root category is anonymous but can be accessed with the
Category.getRoot() method. There is no default appender
attached to root.
<tr><td>x <td>A-x1, A-x2 <td>true <td>A1, A-x1, A-x2
<td>Appenders of "x" and root.
<tr><td>x.y <td>none <td>true <td>A1, A-x1, A-x2
<td>Appenders of "x" and root.
<tr><td>x.y.z <td>A-xyz1 <td>true <td>A1, A-x1, A-x2, A-xyz1
<td>Appenders in "x.y.z", "x" and root.
<tr><td>security <td>A-sec <td><font color="blue">false</font>
<td>A-sec
<td>No appender accumulation since the additivity flag is set to
<code>false</code>.
<tr><td>security.access <td>none <td> true <td> A-sec <td>Only
appenders of "security" because the additivity flag in "security" is
set to <code>false</code>.
</table>
<para>More often than not, users wish to customize not only the output
destination but also the output format. This is accomplished by
associating a <emphasis>layout</emphasis> with an appender. The layout is
responsible for formatting the logging request according to the user's
wishes, whereas an appender takes care of sending the formatted output
to its destination.
The <a
href="api/org/apache/log4j/PatternLayout.html">PatternLayout</a>, part
of the standard log4j distribution, lets the user specify the output
format according to conversion patterns similar to the C language
<code>printf</code> function.
<para>For example, the PatternLayout with the conversion pattern "%r [%t]
%-5p %c - %m%n" will output something akin to:
<pre>
176 [main] INFO org.foo.Bar - Located nearest gas station.
</pre>
<para>The first field is the number of milliseconds elapsed since the
start of the program. The second field is the thread making the log
request. The third field is the priority of the log statement. The
fourth field is the name of the category associated with the log
request. The text after the '-' is the message of the statement.
<para>Just as importantly, log4j will render the content of the log
message according to user specified criteria. For example, if you
frequently need to log <code>Oranges</code>, an object type used in
your current project, then you can register an
<code>OrangeRenderer</code> that will be invoked whenever an orange
needs to be logged.
<para>Object rendering follows the class hierarchy. For example, assuming
oranges are fruits, if you register an <code>FruitRenderer</code>, all
fruits including oranges will be rendered by the
<code>FruitRenderer</code>, unless of course you registered an orange
specific <code>OrangeRenderer</code>.
<para>Object renderers have to implement the
<a href="api/org/apache/log4j/or/ObjectRenderer.html">ObjectRenderer</a>
interface.
<sect1>
<title>Performance</title>
<para></para>
</sect1>
</chapter>
<!--
Local Variables:
sgml-parent-document: ("manual.xml" "book" "chapter")
End:
-->
1.1 jakarta-log4j/src/docbook/configuration.xml
Index: configuration.xml
===================================================================
<chapter id="chap-configuration">
<title>Configuration</title>
<sect1>
<title>PropertyConfigurator</title>
<para></para>
</sect1>
<sect1>
<title>DOMConfigurator</title>
<para></para>
</sect1>
<sect1>
<title>Default configuration</title>
<para></para>
</sect1>
<sect1>
<title>Filters</title>
<para></para>
</sect1>
<sect1>
<title>Error handlers</title>
<para></para>
</sect1>
<sect1>
<title>Category Factories</title>
<para></para>
</sect1>
</chapter>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
