Corrections to documentation. Submitted by Dennis Lundberg.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@139003 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
@@ -4,7 +4,6 @@
|
||||
<extend>../commons-build/project.xml</extend>
|
||||
<name>Logging</name>
|
||||
<id>commons-logging</id>
|
||||
<logo></logo>
|
||||
<currentVersion>1.0-dev</currentVersion>
|
||||
|
||||
<organization>
|
||||
|
||||
+11
-11
@@ -13,7 +13,7 @@
|
||||
<p>
|
||||
The Jakarta Commons Logging (JCL) provides a Log interface that
|
||||
is intended to be both light-weight and independent of numerous logging toolkits.
|
||||
It provides the middleware/tooling developer a simple
|
||||
It provides the middleware/tooling developer with a simple
|
||||
logging abstraction, that allows the user (application developer) to plug in
|
||||
a specific logging implementation.
|
||||
</p>
|
||||
@@ -25,8 +25,8 @@ Familiarity with high-level details of various Logging implementations is presum
|
||||
<p>
|
||||
The Jakarta Commons Logging provides a Log interface with thin-wrapper implementations for
|
||||
other logging tools, including
|
||||
<a href="http://jakarta.apache.org/log4j/docs/index.html">Log4J</a>,
|
||||
<a href="http://jakarta.apache.org/avalon/logkit/index.html">Avalon LogKit</a>,
|
||||
<a href="http://logging.apache.org/log4j/docs/index.html">Log4J</a>,
|
||||
<a href="http://avalon.apache.org/logkit/index.html">Avalon LogKit</a>,
|
||||
and
|
||||
<a>JDK 1.4</a>.
|
||||
The interface maps closely to Log4J and LogKit.
|
||||
@@ -187,7 +187,7 @@ only needs to execute in support of logging,
|
||||
that otherwise introduces undesirable runtime overhead
|
||||
in the general case (logging disabled).
|
||||
Examples are multiple parameters, or expressions (i.e. string + " more") for parameters.
|
||||
Use the guard methods of the form <code>log.is<<i>Priority</i>>()</code> to verify
|
||||
Use the guard methods of the form <code>log.is<<i>Priority</i>>()</code> to verify
|
||||
that logging should be performed, before incurring the overhead of the logging method call.
|
||||
Yes, the logging methods will perform the same check, but only after resolving parameters.
|
||||
</p>
|
||||
@@ -223,7 +223,7 @@ so be conservative and keep to a minimum.
|
||||
See also <a HREF="#Internationalization">Internationalization</a>.
|
||||
</li>
|
||||
<li>
|
||||
<b>debug</b> - detailed information on flow of through the system.
|
||||
<b>debug</b> - detailed information on the flow through the system.
|
||||
Expect these to be written to logs only.
|
||||
</li>
|
||||
<li>
|
||||
@@ -246,7 +246,7 @@ to follow the rules.
|
||||
Since any problems that result are going to be assigned to you,
|
||||
it's in your best interest to be prepared with the proactive
|
||||
tools necessary to demonstrate that your component works correctly,
|
||||
or at worst that the problem analyzed from your logs.
|
||||
or at worst that the problem can be analyzed from your logs.
|
||||
For this discussion, we must make a distinction between different types of exceptions
|
||||
based on what kind of boundaries they cross:
|
||||
</p>
|
||||
@@ -344,7 +344,7 @@ for working with NLS messages.
|
||||
</p>
|
||||
<p>
|
||||
NLS enabled components are particularly appreciated
|
||||
(thats an open-source-correct term for 'required by corporate end-users' :-)
|
||||
(that's an open-source-correct term for 'required by corporate end-users' :-)
|
||||
for <strong>tooling</strong> and <strong>middleware</strong> components.
|
||||
</p>
|
||||
<p>
|
||||
@@ -391,7 +391,7 @@ for the following toolkits, in order of preference:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="http://jakarta.apache.org/log4j/docs/index.html">Log4J</a>
|
||||
<a href="http://logging.apache.org/log4j/docs/index.html">Log4J</a>
|
||||
</li>
|
||||
<li>
|
||||
JDK 1.4
|
||||
@@ -443,13 +443,13 @@ can be configured to use different logging toolkits.
|
||||
Configuration of the behavior of the JCL ultimately depends upon the
|
||||
logging toolkit being used.
|
||||
The JCL SPI uses
|
||||
<a href="http://jakarta.apache.org/log4j/docs/index.html">Log4J</a>
|
||||
<a href="http://logging.apache.org/log4j/docs/index.html">Log4J</a>
|
||||
by default if it is available (in the CLASSPATH).
|
||||
</p>
|
||||
<subsection name='Log4J'>
|
||||
<p>
|
||||
As
|
||||
<a href="http://jakarta.apache.org/log4j/docs/index.html">Log4J</a>
|
||||
<a href="http://logging.apache.org/log4j/docs/index.html">Log4J</a>
|
||||
is the default logger,
|
||||
a <i>few</i> details are presented herein to get the developer/integrator going.
|
||||
</p>
|
||||
@@ -513,7 +513,7 @@ while limiting console output to INFO (and higher).
|
||||
<p>
|
||||
JCL doesn't (and cannot) impose any requirement on thread safety on the underlying implementation
|
||||
and thus its SPI contract doesn't guarantee thread safety.
|
||||
However, JCL can be safely used a multi-threaded environment
|
||||
However, JCL can be safely used in a multi-threaded environment
|
||||
as long as the underlying implementation is thread-safe.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
+1
-1
@@ -43,7 +43,7 @@ package. In addition, there is a (short)
|
||||
<subsection name='Mirrored Releases'>
|
||||
<p>
|
||||
Releases after 1.0.2 should be downloaded from a mirror. Please remember to verify the
|
||||
sigature of the release from the
|
||||
signature of the release from the
|
||||
<a href='http://www.apache.org/dist/jakarta/commons/logging/'>main apache site</a>
|
||||
when downloading from a mirror.
|
||||
</p>
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
|
||||
<!DOCTYPE project [
|
||||
<!ENTITY commons-nav SYSTEM "../../incl_nav.xml">
|
||||
<!ENTITY commons-nav SYSTEM "../../commons-build/incl_nav.xml">
|
||||
]>
|
||||
|
||||
<project name="Logging">
|
||||
|
||||
Reference in New Issue
Block a user