commons-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From denn...@apache.org
Subject svn commit: r569145 - /commons/proper/logging/trunk/RELEASE-NOTES.txt
Date Thu, 23 Aug 2007 20:56:52 GMT
Author: dennisl
Date: Thu Aug 23 13:56:51 2007
New Revision: 569145

URL: http://svn.apache.org/viewvc?rev=569145&view=rev
Log:
Replace "JCL" with "Commons Logging".
Reformat sligthly because "Commons Logging" is wider than "JCL".

Modified:
    commons/proper/logging/trunk/RELEASE-NOTES.txt

Modified: commons/proper/logging/trunk/RELEASE-NOTES.txt
URL: http://svn.apache.org/viewvc/commons/proper/logging/trunk/RELEASE-NOTES.txt?rev=569145&r1=569144&r2=569145&view=diff
==============================================================================
--- commons/proper/logging/trunk/RELEASE-NOTES.txt (original)
+++ commons/proper/logging/trunk/RELEASE-NOTES.txt Thu Aug 23 13:56:51 2007
@@ -26,8 +26,8 @@
 INTRODUCTION:
 ============
 
-This release of Apache Commons Logging (JCL) is a maintenance release, with
-just a couple of fixes for using JCL under restrictive security policies.
+This release of Apache Commons Logging is a maintenance release, with just a
+couple of fixes for using Commons Logging under restrictive security policies.
 
 All core classes were compiled with Maven using a 1.4.x JDK, with target set
 to 1.1 and source set to 1.2. Commons Logging may work on some
@@ -57,15 +57,15 @@
 The protected method LogFactory.getContextClassLoader has been reverted to pre-1.1
 behaviour. In earlier releases, this method did not use an AccessController when
 obtaining the context classloader. In version 1.1 it did. In this release, it has
-reverted to not using an AccessController; any user-level code that needs to obtain a
-context classloader should itself create an AccessController, and call the
+reverted to not using an AccessController; any user-level code that needs to obtain
+a context classloader should itself create an AccessController, and call the
 LogFactory.getContextClassLoader method via the doPrivileged method. This fixes a
 potential security issue, where untrusted code could get access to the context
-classloader if a signed JCL library was in the classpath.
+classloader if a signed Commons Logging library was in the classpath.
 
 == Dependencies ==
 
-Commons-logging has no mandatory dependencies.
+Commons Logging has no mandatory dependencies.
 
 Java 1.2 and later are supported. It may be possible to use this release with
 java 1.1 but this has not been tested; the unit tests certainly don't run on
@@ -79,8 +79,8 @@
 File commons-logging-adapters-nn.jar includes only the adapters to various
 concrete logging libraries. When commons-logging-nn.jar or
 commons-logging-api-nn.jar is deployed in a container classpath, then this
-adapters-only jar file should be deployed in the webapp, not the complete JCL
-distribution. This ensures that the core Log/LogFactory classes are only
+adapters-only jar file should be deployed in the webapp, not the complete Commons
+Logging distribution. This ensures that the core Log/LogFactory classes are only
 deployed via one classloader, thus avoiding "Log4JLogger does not implement Log"
 and similar problems.
 
@@ -92,17 +92,17 @@
 projects that care about "transitive dependencies" and can't handle jar files
 such as commons-logging-nn.jar which have "optional" dependencies depending on
 how they are used. In addition, this jar file can be useful for "rebundlers" of
-JCL who recompile the source-code but who may not be able to recompile against
-the full set of supported adapters; such projects should be able to at least
-recreate an equivalent of this jar file.
+Commons Logging who recompile the source-code but who may not be able to
+recompile against the full set of supported adapters; such projects should be
+able to at least recreate an equivalent of this jar file.
 
 == General Notes ==
 
 The Apache Commons project has migrated to the Subversion version control system
-(previously, CVS was used). There should be no effect on users of the JCL
-library, but obviously the process of examining the latest source code, and of
-creating patches for JCL has now changed. Please see the Apache Commons
-website for details (http://commons.apache.org/).
+(previously, CVS was used). There should be no effect on users of the Commons
+Logging library, but obviously the process of examining the latest source code,
+and of creating patches for Commons Logging has now changed. Please see the
+Apache Commons website for details (http://commons.apache.org/).
 
 The Apache Commons project has now moved to using the Apache JIRA installation
 as its bugtracking system (formerly, the Apache Bugzilla installation was used).
@@ -118,16 +118,17 @@
 
 == Bugs Fixed ==
 
-* LOGGING-106: JCL 1.1 was completely unusable under a security policy that prevented
-  access to system properties. Even signing/authorising the JCL library was not
-  sufficient. This has been fixed by (a) catching SecurityException and falling back
-  to a sensible default, and (b) using AccessController so JCL can be granted
-  privileges without needing the caller to have them too. 
-
-* LOGGING-107: JCL 1.1 auto-discovery failed under a security policy that prevented
-  calls to ClassLoader.getParent. Signing/authorising the JCL library was not
-  sufficient as an AccessController was not used. This has been fixed by catching
-  SecurityException and using an AccessController.
+* LOGGING-106: Commons Logging 1.1 was completely unusable under a security
+  policy that prevented access to system properties. Even signing/authorising
+  the Commons Logging library was not sufficient. This has been fixed by (a)
+  catching SecurityException and falling back to a sensible default, and (b)
+  using AccessController so Commons Logging can be granted privileges without
+  needing the caller to have them too.
+
+* LOGGING-107: Commons Logging 1.1 auto-discovery failed under a security
+  policy that prevented calls to ClassLoader.getParent. Signing/authorising the
+  Commons Logging library was not sufficient as an AccessController was not used.
+  This has been fixed by catching SecurityException and using an AccessController.
 
 * LOGGING-111: Show the contents of chained exceptions, to make debugging easier,
   in particular when using Commons Logging together with Log4J.
@@ -135,19 +136,20 @@
 * LOGGING-113: pom.xml in maven repository does not list dependencies as optional.
 
 * MEV-392 (http://jira.codehaus.org/browse/MEV-392)
-  As JCL didn't provide a Maven2 pom.xml file, one was helpfully created by people
-  not involved with the commons-logging project and published to the standard maven
-  repositories. Unfortunately this pom declared normal dependencies on all the logging
-  libraries that are supported by the core JCL distribution, meaning they all get pulled
-  into a project that declares a dependency on JCL1.1. This release now provides an
+  As Commons Logging didn't provide a Maven2 pom.xml file, one was helpfully
+  created by people not involved with the commons-logging project and published
+  to the standard maven repositories. Unfortunately this pom declared normal
+  dependencies on all the logging libraries that are supported by the core
+  Commons Logging distribution, meaning they all get pulled into a project that
+  declares a dependency on Commons Logging 1.1. This release now provides an
   "official" pom.xml which declares these dependencies as optional so they aren't
-  automatically included in projects that depend on JCL 1.1.1.
+  automatically included in projects that depend on Commons Logging 1.1.1.
 
 * (no bug#): Fix thread-safety bug (SimpleDateFormat.format is not thread-safe).
   Thanks to Martin Wilson of bright-interactive for the bug report.
 
-* (no bug#): Security issue regarding access to context classloader (see incompatibilities
-  section above).
+* (no bug#): Security issue regarding access to context classloader (see
+  incompatibilities section above).
 
 DEPRECATIONS:
 ============



Mime
View raw message