You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by ce...@apache.org on 2005/02/10 14:06:36 UTC
cvs commit: logging-log4j/docs faq.html ugli.html
ceki 2005/02/10 05:06:36
Modified: src/xdocs ugli.xml faq.xml
docs faq.html ugli.html
Log:
doc updates
Revision Changes Path
1.6 +28 -23 logging-log4j/src/xdocs/ugli.xml
Index: ugli.xml
===================================================================
RCS file: /home/cvs/logging-log4j/src/xdocs/ugli.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ugli.xml 21 Jan 2005 18:37:24 -0000 1.5
+++ ugli.xml 10 Feb 2005 13:06:36 -0000 1.6
@@ -14,8 +14,8 @@
intended to serve as a simple abstraction of various logging
APIs allowing to plug in the desired implementation at
deployment time. Note that log4j version 1.3 and later support
- UGLI directly as log4j itself is implemented in terms of the
- UGLI interface.
+ UGLI directly. Log4j is implemented in terms of the UGLI
+ interfaces.
</p>
<h2>Typical usage pattern</h2>
@@ -58,8 +58,14 @@
Simple, JDK 1.4 logging and log4j. Log4j 1.3 ships with four
jar files <em>ugli-nop.jar</em>, <em>ugli-simple.jar</em>,
<em>ugli-jdk14.jar</em> and <em>log4j.jar</em>. Each of these
- jar files are hardwired to use just one implementation, that
- is NOP, Simple, JDK 1.4 logging and log4j, respectively.
+ jar files are hardwired <em>at compile-time</em> to use just one
+ implementation, that is NOP, Simple, JDK 1.4 logging and log4j,
+ respectively.
+ </p>
+
+ <p>Small applications where configuring log4j can be somewhat
+ of an overkill can drop in <em>ugli-simple.jar</em> in place
+ of <em>log4j.jar</em>.
</p>
<p>Authors of widely-distributed components and libraries may
@@ -67,34 +73,30 @@
logging API implementation on the end-user. At deployment
time, the end-user may choose the desired logging API
implementation by inserting the corresponding jar file in her
- classpath. This stupid, simple and relatively robust approach
- avoids many of the painful bugs associated with dynamic
- discovery processes based on fragile classloader hacks. Life
- is too short to be spending it resolving classloader bugs.
+ classpath. This stupid, simple but robust approach avoids many
+ of the painful bugs associated with dynamic discovery
+ processes. Life is too short to be spending it hunting down
+ class loader problems.
</p>
- <p>Small applications where configuring log4j can be somewhat
- of an overkill can drop in <em>ugli-simple.jar</em> in place
- of <em>log4j.jar</em>.
- </p>
-
<h2>Simplicity</h2>
<p>The UGLI interfaces and their various adapters are
extremely simple. Most developers familiar with the Java
language should be able to read and fully understand the code
- in less than one hour.
+ in less than one hour.
</p>
- <p>Just as importantly, UGLI does not rely on any
- classloader tricks. Every variant of
- <em>ugli-<impl>.jar</em> is hardwired to use one
- specific implementation.</p>
-
+ <p>As noted earlier, UGLI does not rely on any classloader
+ tricks. Every variant of <em>ugli-<impl>.jar</em> is
+ statically hardwired (at compile time) to use one specific
+ implementation. Thus, UGLI suffers from none of the <a
+ href="http://www.qos.ch/logging/classloader.jsp">class loader
+ problems observed when using JCL</a>.</p>
- <p>The simplicity of the UGLI interfaces and the deployment
- model make it easy for developers of other logging APIs to
- easily conform to the UGLI model.
+ <p>We hope that simplicity of the UGLI interfaces and the
+ deployment model will make it easy for developers of other
+ logging APIs to conform to the UGLI model.
</p>
<h2>Built-in support in log4j</h2>
@@ -113,6 +115,10 @@
computational overhead is so small as to be unobservable.
</p>
+ <h2>Where can I get UGLI?</h2>
+
+ <p>UGLI ships with log4j version 1.3alpha-6 and later.</p>
+
<h2>Summary</h2>
<table class="ls" cellspacing="4" cellpadding="4">
@@ -164,7 +170,6 @@
<td>All UGLI adapters support parameterized log messages.</td>
</tr>
-
<tr>
<td>Built-in support in log4j</td>
1.7 +10 -8 logging-log4j/src/xdocs/faq.xml
Index: faq.xml
===================================================================
RCS file: /home/cvs/logging-log4j/src/xdocs/faq.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- faq.xml 8 Dec 2004 17:22:20 -0000 1.6
+++ faq.xml 10 Feb 2005 13:06:36 -0000 1.7
@@ -361,7 +361,7 @@
<h3>Better alternative based on message patterns</h3>
<p>As of log4j version 1.3, there exists a significantly more
convenient alternative based on message patterns. Assuming
- <code>entry</code> is a non-primitive object, you can write:
+ <code>entry</code> is an object, you can write:
</p>
<p class="source">
@@ -369,15 +369,17 @@
</p>
<p>After evaluting whether to log or not, and only if the
- decision is affirmative, the logger instace will format the
- message and replace the '{}' pair with the string value of the
- <code>entry</code> parameter.
+ decision is positive, will the logger instace format the
+ message and replace the '{}' pair with the string value of
+ <code>entry</code>. In other words, the paramerized form does
+ not incur the cost of parameter construction in case the log
+ statement is disabled.
</p>
- <p>Thus, the following two lines will yield the exact sane
+ <p>Thus, the following two lines will yield the exact same
output. However, the second form will perform at least 30
- (yes, thirty, the cardinal number equal to 3x10) times faster
- in case of a <em>disabled</em> logging statement.
+ (thirty) times faster in case of a <em>disabled</em> logging
+ statement.
</p>
<p class="source">
@@ -386,7 +388,7 @@
</p>
<p>A two argument variant is also availalble. For example, you
- can also write:
+ can write:
</p>
<p class="source">
l.debug("The new entry is {}. It replaces {}.", entry, oldEntry);
1.8 +11 -9 logging-log4j/docs/faq.html
Index: faq.html
===================================================================
RCS file: /home/cvs/logging-log4j/docs/faq.html,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- faq.html 3 Jan 2005 15:26:56 -0000 1.7
+++ faq.html 10 Feb 2005 13:06:36 -0000 1.8
@@ -538,7 +538,7 @@
<h3>Better alternative based on message patterns</h3>
<p>As of log4j version 1.3, there exists a significantly more
convenient alternative based on message patterns. Assuming
- <code>entry</code> is a non-primitive object, you can write:
+ <code>entry</code> is an object, you can write:
</p>
<p class="source">
@@ -546,15 +546,17 @@
</p>
<p>After evaluting whether to log or not, and only if the
- decision is affirmative, the logger instace will format the
- message and replace the '{}' pair with the string value of the
- <code>entry</code> parameter.
+ decision is positive, will the logger instace format the
+ message and replace the '{}' pair with the string value of
+ <code>entry</code>. In other words, the paramerized form does
+ not incur the cost of parameter construction in case the log
+ statement is disabled.
</p>
- <p>Thus, the following two lines will yield the exact sane
+ <p>Thus, the following two lines will yield the exact same
output. However, the second form will perform at least 30
- (yes, thirty, the cardinal number equal to 3x10) times faster
- in case of a <em>disabled</em> logging statement.
+ (thirty) times faster in case of a <em>disabled</em> logging
+ statement.
</p>
<p class="source">
@@ -563,7 +565,7 @@
</p>
<p>A two argument variant is also availalble. For example, you
- can also write:
+ can write:
</p>
<p class="source">
l.debug("The new entry is {}. It replaces {}.", entry, oldEntry);
@@ -1082,7 +1084,7 @@
<!-- FOOTER -->
<div align="center"><font color="#525D76" size="-1"><em>
- Copyright © 1999-2004, Apache Software Foundation
+ Copyright © 1999-2005, Apache Software Foundation
</em></font></div>
<!-- END main table -->
1.6 +30 -26 logging-log4j/docs/ugli.html
Index: ugli.html
===================================================================
RCS file: /home/cvs/logging-log4j/docs/ugli.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ugli.html 21 Jan 2005 18:37:24 -0000 1.5
+++ ugli.html 10 Feb 2005 13:06:36 -0000 1.6
@@ -53,8 +53,8 @@
intended to serve as a simple abstraction of various logging
APIs allowing to plug in the desired implementation at
deployment time. Note that log4j version 1.3 and later support
- UGLI directly as log4j itself is implemented in terms of the
- UGLI interface.
+ UGLI directly. Log4j is implemented in terms of the UGLI
+ interfaces.
</p>
<h2>Typical usage pattern</h2>
<pre class="source">
@@ -91,36 +91,38 @@
Simple, JDK 1.4 logging and log4j. Log4j 1.3 ships with four
jar files <em>ugli-nop.jar</em>, <em>ugli-simple.jar</em>,
<em>ugli-jdk14.jar</em> and <em>log4j.jar</em>. Each of these
- jar files are hardwired to use just one implementation, that
- is NOP, Simple, JDK 1.4 logging and log4j, respectively.
+ jar files are hardwired <em>at compile-time</em> to use just one
+ implementation, that is NOP, Simple, JDK 1.4 logging and log4j,
+ respectively.
+ </p>
+ <p>Small applications where configuring log4j can be somewhat
+ of an overkill can drop in <em>ugli-simple.jar</em> in place
+ of <em>log4j.jar</em>.
</p>
<p>Authors of widely-distributed components and libraries may
code against the UGLI interface in order to avoid imposing an
logging API implementation on the end-user. At deployment
time, the end-user may choose the desired logging API
implementation by inserting the corresponding jar file in her
- classpath. This stupid, simple and relatively robust approach
- avoids many of the painful bugs associated with dynamic
- discovery processes based on fragile classloader hacks. Life
- is too short to be spending it resolving classloader bugs.
- </p>
- <p>Small applications where configuring log4j can be somewhat
- of an overkill can drop in <em>ugli-simple.jar</em> in place
- of <em>log4j.jar</em>.
+ classpath. This stupid, simple but robust approach avoids many
+ of the painful bugs associated with dynamic discovery
+ processes. Life is too short to be spending it hunting down
+ class loader problems.
</p>
<h2>Simplicity</h2>
<p>The UGLI interfaces and their various adapters are
extremely simple. Most developers familiar with the Java
language should be able to read and fully understand the code
- in less than one hour.
+ in less than one hour.
</p>
- <p>Just as importantly, UGLI does not rely on any
- classloader tricks. Every variant of
- <em>ugli-<impl>.jar</em> is hardwired to use one
- specific implementation.</p>
- <p>The simplicity of the UGLI interfaces and the deployment
- model make it easy for developers of other logging APIs to
- easily conform to the UGLI model.
+ <p>As noted earlier, UGLI does not rely on any classloader
+ tricks. Every variant of <em>ugli-<impl>.jar</em> is
+ statically hardwired (at compile time) to use one specific
+ implementation. Thus, UGLI suffers none of the <a href="http://www.qos.ch/logging/classloader.jsp">class loader
+ problems observed when using JCL</a>.</p>
+ <p>We hope that simplicity of the UGLI interfaces and the
+ deployment model will make it easy for developers of other
+ logging APIs to conform to the UGLI model.
</p>
<h2>Built-in support in log4j</h2>
<p>The <code>Logger</code> class in log4j directly implements
@@ -135,6 +137,8 @@
memory overhead and near-zero computational overhead. The
computational overhead is so small as to be unobservable.
</p>
+ <h2>Where can I get UGLI?</h2>
+ <p>UGLI ships with log4j version 1.3alpha-6 and later.</p>
<h2>Summary</h2>
<table class="ls" cellspacing="4" cellpadding="4">
<tr>
@@ -151,9 +155,10 @@
<p>Contrast this with
<code>LogConfigurationException</code> thrown by
- commons-logging which will cause your otherwise functional
- application to fail. Commons-logging will throw a
- <code>LogConfigurationException</code> in case the <a href="http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/Log.html">Log</a>
+ commons-logging which will cause your otherwise
+ functioning application to fail. Commons-logging will
+ throw a <code>LogConfigurationException</code> in case the
+ <a href="http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/Log.html">Log</a>
interface and its dynamically discovered implementation
are loaded by different class loaders.
</p>
@@ -183,7 +188,6 @@
<td>All UGLI adapters support parameterized log messages.</td>
</tr>
-
<tr>
<td>Built-in support in log4j</td>
@@ -195,10 +199,10 @@
- <hr/>
+ <hr/>
-
+
<!-- FOOTER -->
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org