1
0
Files
tweed5-commons-logging/RELEASE-NOTES.txt
2005-06-16 12:11:50 +00:00

113 lines
4.6 KiB
Plaintext

<!--
Copyright 2005 The Apache Software Foundation.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
$Id$
Commons Logging Package
Version 1.1.0
Release Notes
INTRODUCTION:
============
This release introduces significant changes in the way that discovery of
logging implementations occurs, and how errors are handled. A number of
problems that have troubled users in past releases (particularly the
"Log4JLogger does not implement Log" problem) will hopefully be
significantly reduced or cured.
This release is 100% compatible with existing code that calls
commons-logging. There are some incompatibilities with code that extends
commons-logging, for example to implement custom logging adapters.
== New Features ==
* jars now have release-numbers embedded in the names
* 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
unexpected manner, you can now set system property
org.apache.commons.logging.diagnostics.dest
to the value STDOUT, STDERR or a filename. As commons-logging initialises
itself for each new contextClassLoader it detects, useful information will
be output about which logging library is bound to and why.
* new configurable attributes ALLOW_FLAWED_HIERARCHY, ALLOW_FLAWED_DISCOVERY and
ALLOW_FLAWED_CONTEXT. The default values for these are all true, meaning that
commons-logging attempts to recover from bad logging configuration situations
by finding *some* logger to use even when it isn't quite the one that might
be expected. This will significantly reduce the occurrence of the dreaded
LogConfigurationException on application/webapp startup at the cost of
slightly more ambiguity about where output will go. In cases where no logging
output is generated or wanted (which is the case 99% of the time) this is definitely a
more convenient approach. Users who 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.
* ServletContextCleaner class now provided to ensure memory is released
when undeploying webapps. This does require an entry in the webapp
deployment descriptor to enable.
== Incompatibilities ==
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.
== Bugs Fixed ==
* 31597: problem where log4j adapter in parent classloader but log4j.jar was
in child classloader led to failure to initialise logging has been
fixed.
* 31710, 10825: commons-logging now works better in systems where getClassLoader
returns null. This essentially means embedded systems.
* 31818: workaround for bug in java1.2 compiler; code now compiles under 1.2
* Log4JCategoryLog has been removed from the main distribution jar; it has been
deprecated for a long while. Replacement class Log4JLogger should be a completely
transparent replacement for all commons-logging users.
* package.html files are no longer present in the jarfiles, removing nuisance
javadoc warnings when building javadoc for apps using jcl.
* In several cases, LogConfigurationException objects were being wrapped in
other LogConfigurationException objects. These have (hopefully) all been
fixed.
DEPRECATIONS:
============
(These are carried forward from Version 1.0.3)
[LogSource] Previously deprecated, replaced by LogFactory.
[Log4jFactory] A proxy instance of this class was transparently created
when Log4J logging was selected, yet it serves no useful
purpose. The class is now deprecated, and the proxy
instance is no longer created.