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

Some updates (not complete yet).

Browse Source 
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@370384 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Simon Kitching
2006-01-19 05:31:09 +00:00
parent 73f2a07e70
commit c0de38481c
1 changed files with 79 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

107
RELEASE-NOTES.txt
View File

@@ -1,6 +1,6 @@
<!-- <!--
Copyright 2005 The Apache Software Foundation. Copyright 2005,2006 The Apache Software Foundation.
Licensed under the Apache License, Version 2.0 (the "License"); Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License. you may not use this file except in compliance with the License.
@@ -26,6 +26,9 @@ $Id$
INTRODUCTION: INTRODUCTION:
============ ============
This release of Jakarta Commons Logging (JCL) is a maintenance release, with a
few new configuration features but no major changes in services provided.
This release introduces significant changes in the way that discovery of This release introduces significant changes in the way that discovery of
logging implementations occurs, and how errors are handled. A number of logging implementations occurs, and how errors are handled. A number of
problems that have troubled users in past releases (particularly the problems that have troubled users in past releases (particularly the
@@ -34,51 +37,97 @@ significantly reduced or cured.
This release is 100% compatible with existing code that calls This release is 100% compatible with existing code that calls
commons-logging. There are some incompatibilities with code that extends commons-logging. There are some incompatibilities with code that extends
commons-logging, for example to implement custom logging adapters. commons-logging, for example to implement custom logging adapters. See
the compatibility section for details.
For further details, please see the Jakarta Commons Logging website:
http://jakarta.apache.org/commons/logging.
For the very latest news, hints, FAQs etc. please see the
Jakarta Commons Logging wiki site:
http://wiki.apache.org/jakarta-commons/Logging
== New Features == == New Features ==
* jars now have release-numbers embedded in the names * Jarfiles now have release-numbers embedded in the names, for easier management.
* commons-logging-adapters-xxx.jar now included.
* creation of optional jar containing WeakHashtable implementation
Changes to LogFactory to use a WeakHashtable if one is available.
* added internal diagnostics feature. If commons-logging is behaving in an * New jarfile commons-logging-adapters-xxx.jar is now provided. This can be
used to resolve class cast conflicts where parts of commons-logging are
deployed via different classloaders.
* New internal diagnostics feature. If commons-logging is behaving in an
unexpected manner, you can now set system property unexpected manner, you can now set system property
org.apache.commons.logging.diagnostics.dest org.apache.commons.logging.diagnostics.dest
to the value STDOUT, STDERR or a filename. As commons-logging initialises to the value STDOUT, STDERR or a filename. As commons-logging initialises
itself for each new contextClassLoader it detects, useful information will itself for each new contextClassLoader it detects, useful information will
be output about which logging library is bound to and why. be output about which logging library is bound to and why.
* new configurable attributes ALLOW_FLAWED_HIERARCHY, ALLOW_FLAWED_DISCOVERY and * JCL now prefers to "make a best attempt" in problem scenarios rather than
ALLOW_FLAWED_CONTEXT. The default values for these are all true, meaning that report an error and fail to initialise. New configurable attributes
commons-logging attempts to recover from bad logging configuration situations ALLOW_FLAWED_HIERARCHY, ALLOW_FLAWED_DISCOVERY and ALLOW_FLAWED_CONTEXT are
by finding *some* logger to use even when it isn't quite the one that might provided to control startup behavior. The default values for these are all
be expected. This will significantly reduce the occurrence of the dreaded true, meaning that commons-logging attempts to recover from bad logging
LogConfigurationException on application/webapp startup at the cost of configuration situations by finding *some* logger to use even when it isn't
slightly more ambiguity about where output will go. In cases where no logging quite the one that might be expected. This will significantly reduce the
output is generated or wanted (which is the case 99% of the time) this is definitely a occurrence of the dreaded LogConfigurationException on application/webapp
more convenient approach. Users who cannot figure out where logging went or startup at the cost of slightly more ambiguity about where output will go.
why it went to an unexpected destination can enable diagnostics to find out, In cases where no logging output is generated or wanted (which is the case
or set the ALLOW_FLAWED_ settings to false to force LogConfigurationException 99% of the time) this is definitely a more convenient approach. Users who
to be thrown as in earlier releases. cannot figure out where logging went or why it went to an unexpected
destination can enable diagnostics to find out, or set the ALLOW_FLAWED_
settings to false to force LogConfigurationException to be thrown as in
earlier releases.
* Fix for the problem where memory was not being released under some circumstances
when a webapp was undeployed. An internal change fixes some situations where
that occurs (by using weak references); this requires no action on the part of
users of this library. In addition, a utility class ServletContextCleaner is
provided in the jarfile which is expected to resolve this problem in all
situations; however it is necessary for an application to define this class as
a ServletContextListener in the web.xml in order for this to be invoked.
* ServletContextCleaner class now provided to ensure memory is released * Prioritised commons-logging.properties files. A file with the name
when undeploying webapps. This does require an entry in the webapp "commons-logging.properties" placed in the classpath can be used to set
deployment descriptor to enable. various JCL configuration options. In previous releases, the first
such file found in the classpath was used to configure JCL. Now, each file
can have an entry "priority", and the file with the highest priority is used.
Where two files have equal priority, the first one in the classpath is used;
this maintains backwards compatibility.
* New feature to disable loading of logging classes via the thread context
classloader (TCCL), on a per-webapp basis. Simply putting an entry
"use_tccl=false" in a commons-logging.properties file will ensure that
all classes used for logging are loaded via the same classloader that
loads the LogFactory class. This resolves any "class cast" issues with
JCL, though at the price of losing some control over logging configuration.
* The log4j logging adapter now supports the TRACE level (added to log4j 1.2.12).
Formerly, any calls to log.trace were output at the log4j debug level.
== Incompatibilities == == Incompatibilities ==
The isXXXAvailable methods in org.apache.commons.logging.impl.LogFactoryImpl There are no changes for code that calls LogFactory or Log methods. This means
are no longer called during discovery by that class. Therefore classes which that any application which is a simple "user" of the JCL library can safely
subclass LogFactoryImpl and override those methods will not have their upgrade to this version.
methods called. This is a pretty unusual thing to do, so it isn't expected that
any apps will actually be affected by this. All changes to JCL configuration are backwards compatible.
For code that extends the JCL LogFactoryImpl class, the isXXXAvailable methods
in org.apache.commons.logging.impl.LogFactoryImpl are no longer called during
discovery by that class. Therefore classes which subclass LogFactoryImpl and
override those methods will not have their methods called. This is a pretty
unusual thing to do, so it isn't expected that any apps will actually be
affected by this.
== General Notes ==
Log4J 1.3 is expected to include a binary-incompatible change from the 1.2 series that
unfortunately makes it impossible for a single adapter class to support both.
This release does not include support for Log4J 1.3.
== Bugs Fixed == == Bugs Fixed ==
* 31597: problem where log4j adapter in parent classloader but log4j.jar was * 31597: problem where log4j adapter was in parent classloader but log4j.jar was
in child classloader led to failure to initialise logging has been in child classloader led to failure to initialise logging has been
fixed. fixed.
@@ -101,7 +150,7 @@ any apps will actually be affected by this.
DEPRECATIONS: DEPRECATIONS:
============ ============
(These are carried forward from Version 1.0.3) (These are carried forward from Version 1.0.4)
[LogSource] Previously deprecated, replaced by LogFactory. [LogSource] Previously deprecated, replaced by LogFactory.