Siphalor/tweed5-commons-logging
1
0
Fork 0
Code Activity

Add section for 1.1 release.

Browse Source 
Other minor updates.


git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@371221 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Simon Kitching
2006-01-22 06:56:46 +00:00
parent 7b1c2b0aac
commit c7d566cf10
1 changed files with 36 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
xdocs/index.xml
View File

@@ -29,15 +29,25 @@
<section name="The Logging Component">
<p>There is a great need for debugging and logging information inside of
Commons components such as HTTPClient and DBCP. However, there are many
logging APIs out there and it is difficult to choose among them.</p>
<p>When writing a library it is very useful to log information. However there
are many logging implementations out there, and a library cannot impose the use
of a particular one on the overall application that the library is a part of.</p>
<p>The Logging package is an ultra-thin bridge between different logging
libraries. Commons components may use the Logging API to remove
compile-time and run-time dependencies on any particular logging package,
and contributors may write Log implementations for the library of
their choice.</p>
implementations. A library that uses the commons-logging API can be used with
any logging implementation at runtime. Commons-logging comes with support for a
number of popular logging implementations, and writing adapters for others is a
reasonably simple task.</p>
<p>Applications (rather than libraries) may also choose to use commons-logging.
While logging-implementation independence is not as important for applications
as it is for libraries, using commons-logging does allow the application to
change to a different logging implementation without recompiling code. Note
that commons-logging does not attempt to initialise or terminate the underlying
logging implementation that is used at runtime; that is the responsibility of
the application. However many popular logging implementations do automatically
initialise themselves; in this case an application may be able to avoid
containing any code that is specific to the logging implementation used.</p>
</section>
@@ -54,6 +64,9 @@ In particular, you should read the package overview of the <code>org.apache.comm
package. In addition, there is a (short)
<a href="guide.html">User Guide</a>.</p>
<p>The <a href="http://wiki.apache.org/jakarta-commons/Logging">Wiki site</a> has
the latest updates, an FAQ and much other useful information.</p>
<p>
Users needing to become experts or wanting to help develop JCL should
(in addition) consult the <a href='tech.html'>Tech Guide</a>.
@@ -63,14 +76,24 @@ This gives short introductions to topics such as advanced class loading.
<section name="Releases">
<subsection name='1.1 Release'>
<p>This release makes several changes that are intended to resolve issues that
have been encountered when using commons-logging in servlet containers or j2ee
containers where complex classpaths are present and multiple copies of
commons-logging libraries are present at different levels.</p>
<p>This release also adds support for the TRACE level added to log4j in the
1.2.12 release. In former commons-logging versions, the log.trace method
caused log4j to output the message at the DEBUG level (the lowest level
supported by log4j at that time).</p>
<p>For the full details, see the release notes for this version.</p>
</subsection>
<subsection name='1.0.5 Release (Alpha)'>
<p>
<strong>Note:</strong> the 1.0.5 release was abandoned at alpha status.
</p>
<p>
<p>
<strong>Note:</strong> the 1.0.5 release was abandoned at alpha status.
</p>
<p>
The next JCL release will be designated 1.1 since we feel this more
accurately reflects the improvements made to the codebase.
</p>
accurately reflects the improvements made to the codebase.</p>
</subsection>
<subsection name='1.0.4 Release'>
<p>