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

Standardize on American English spelling of 'behavior'.

Browse Source
This commit is contained in:
Gary Gregory
2020-03-30 15:07:28 -04:00
parent 9f99a007cf
commit 7c70d1a180
12 changed files with 27 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/main/java/org/apache/commons/logging/LogFactory.java
View File

@@ -501,7 +501,7 @@ public abstract class LogFactory {
}
// ignore
} catch (RuntimeException e) {
// This is not consistent with the behaviour when a bad LogFactory class is
// This is not consistent with the behavior when a bad LogFactory class is
// specified in a services file.
//
// One possible exception that can occur here is a ClassCastException when
@@ -1302,7 +1302,7 @@ public abstract class LogFactory {
InputStream stream = null;
try {
// We must ensure that useCaches is set to false, as the
// default behaviour of java is to cache file handles, and
// default behavior of java is to cache file handles, and
// this "locks" files, preventing hot-redeploy on windows.
URLConnection connection = url.openConnection();
connection.setUseCaches(false);

26
src/main/java/org/apache/commons/logging/impl/LogFactoryImpl.java
View File

@@ -107,12 +107,12 @@ public class LogFactoryImpl extends LogFactory {
/**
* The name (<code>org.apache.commons.logging.Log.allowFlawedContext</code>)
* of the system property which can be set true/false to
* determine system behaviour when a bad context-classloader is encountered.
* determine system behavior when a bad context-classloader is encountered.
* When set to false, a LogConfigurationException is thrown if
* LogFactoryImpl is loaded via a child classloader of the TCCL (this
* should never happen in sane systems).
*
* Default behaviour: true (tolerates bad context classloaders)
* Default behavior: true (tolerates bad context classloaders)
*
* See also method setAttribute.
*/
@@ -122,13 +122,13 @@ public class LogFactoryImpl extends LogFactory {
/**
* The name (<code>org.apache.commons.logging.Log.allowFlawedDiscovery</code>)
* of the system property which can be set true/false to
* determine system behaviour when a bad logging adapter class is
* determine system behavior when a bad logging adapter class is
* encountered during logging discovery. When set to false, an
* exception will be thrown and the app will fail to start. When set
* to true, discovery will continue (though the user might end up
* with a different logging implementation than they expected).
* <p>
* Default behaviour: true (tolerates bad logging adapters)
* Default behavior: true (tolerates bad logging adapters)
*
* See also method setAttribute.
*/
@@ -138,13 +138,13 @@ public class LogFactoryImpl extends LogFactory {
/**
* The name (<code>org.apache.commons.logging.Log.allowFlawedHierarchy</code>)
* of the system property which can be set true/false to
* determine system behaviour when a logging adapter class is
* determine system behavior when a logging adapter class is
* encountered which has bound to the wrong Log class implementation.
* When set to false, an exception will be thrown and the app will fail
* to start. When set to true, discovery will continue (though the user
* might end up with a different logging implementation than they expected).
* <p>
* Default behaviour: true (tolerates bad Log class hierarchy)
* Default behavior: true (tolerates bad Log class hierarchy)
*
* See also method setAttribute.
*/
@@ -326,7 +326,7 @@ public class LogFactoryImpl extends LogFactory {
* <p>
* This method can be used to set logging configuration programmatically
* rather than via system properties. It can also be used in code running
* within a container (such as a webapp) to configure behaviour on a
* within a container (such as a webapp) to configure behavior on a
* per-component level instead of globally as system properties would do.
* To use this method instead of a system property, call
* <pre>
@@ -399,7 +399,7 @@ public class LogFactoryImpl extends LogFactory {
* including which classloader the object was loaded from.
* <p>
* This string will later be prefixed to each "internal logging" message
* emitted, so that users can clearly see any unexpected behaviour.
* emitted, so that users can clearly see any unexpected behavior.
* <p>
* Note that this method does not detect whether internal logging is
* enabled or not, nor where to output stuff if it is; that is all
@@ -646,7 +646,7 @@ public class LogFactoryImpl extends LogFactory {
/**
* Utility method to check whether a particular logging library is
* present and available for use. Note that this does <i>not</i>
* affect the future behaviour of this class.
* affect the future behavior of this class.
*/
private boolean isLogLibraryAvailable(String name, String classname) {
if (isDiagnosticsEnabled()) {
@@ -735,7 +735,7 @@ public class LogFactoryImpl extends LogFactory {
}
/**
* Get the setting for the user-configurable behaviour specified by key.
* Get the setting for the user-configurable behavior specified by key.
* If nothing has explicitly been set, then return dflt.
*/
private boolean getBooleanConfiguration(String key, boolean dflt) {
@@ -747,7 +747,7 @@ public class LogFactoryImpl extends LogFactory {
}
/**
* Initialize a number of variables that control the behaviour of this
* Initialize a number of variables that control the behavior of this
* class and that can be tweaked by the user. This is done when the first
* logger is created, not in the constructor of this class, because we
* need to give the user a chance to call method setAttribute in order to
@@ -829,7 +829,7 @@ public class LogFactoryImpl extends LogFactory {
// and SimpleLog will always work in any JVM. So the loop would never
// ever look for logging libraries in the parent classpath. Yet many
// users would expect that putting log4j there would cause it to be
// detected (and this is the historical JCL behaviour). So we go with
// detected (and this is the historical JCL behavior). So we go with
// the first approach. A user that has bundled a specific logging lib
// in a webapp should use a commons-logging.properties file or a
// service file in META-INF to force use of that logging lib anyway,
@@ -1007,7 +1007,7 @@ public class LogFactoryImpl extends LogFactory {
// Try the class classloader.
// This may work in cases where the TCCL
// does not contain the code executed or JCL.
// This behaviour indicates that the application
// This behavior indicates that the application
// classloading strategy is not consistent with the
// Java 1.2 classloading guidelines but JCL can
// and so should handle this case.

2
src/site/xdoc/junit-report.xml
View File

@@ -28,7 +28,7 @@ limitations under the License.
<p>
The Apache Commons Logging test cases make extensive use of
sophisticated classloader configurations in order to simulate the
behaviour of various containers. It is difficult to run these tests
behavior of various containers. It is difficult to run these tests
under Maven in the default "test" phase. As a consequence the tests
are executed via the failsafe-plugin as part of the "integration-test"
phase. The reports are available <a href="failsafe-report.html">here</a>.

2
src/site/xdoc/tech.xml
View File

@@ -269,7 +269,7 @@ limitations under the License.
<p>
<em>
In practical development terms: This means that different JVMs may realize that a reference cannot be
resolved at different times during execution. Consequently, the actual behaviour cannot be precisely predicted
resolved at different times during execution. Consequently, the actual behavior cannot be precisely predicted
without intimate knowledge of the JVM (on which the bytecode will be executed).
This makes it hard to give universal guidance to users.
</em>

6
src/site/xdoc/troubleshooting.xml
View File

@@ -424,7 +424,7 @@ implementation.
</p>
<p>
Because the commons-logging-api.jar in the container does not contain any
log-library-adapter classes, updated behaviour for these <i>will</i> be
log-library-adapter classes, updated behavior for these <i>will</i> be
seen when logging 1.1 is bundled in WEB-INF/lib. In particular, the
support for log4j's TRACE level will take effect without having to update
the container.
@@ -440,7 +440,7 @@ implementation.
libraries (eg log4j) within WEB-INF/lib are not accessible.
</p>
<p>
Note that the behaviour described here only applies if the standard Tomcat
Note that the behavior described here only applies if the standard Tomcat
startup process is run. When Tomcat is embedded in a larger
framework (eg run embedded within an IDE) this may not apply.
</p>
@@ -449,7 +449,7 @@ implementation.
<p>
The JBoss Application Server can be configured to prevent deployed
code from overriding classes higher in the hierarchy, effectively
forcing "parent-first" behaviour for selected classes. By default,
forcing "parent-first" behavior for selected classes. By default,
commons-logging is in this list (at least for some JBoss versions
starting with 4.0.2), and therefore including an updated version
of commons-logging in WEB-INF/lib or similar will have no effect.

2
src/test/java/org/apache/commons/logging/BadHashtablePropertyTestCase.java
View File

@@ -21,7 +21,7 @@ import junit.framework.TestCase;
import java.util.Hashtable;
/**
* Tests behaviour when the property is misconfigured.
* Tests behavior when the property is misconfigured.
*/
public class BadHashtablePropertyTestCase extends TestCase {

2
src/test/java/org/apache/commons/logging/PathableTestSuite.java
View File

@@ -94,7 +94,7 @@ import junit.framework.TestSuite;
* settings.
* <p>
* The effect of using this approach in a system that uses junit's
* "reloading classloader" behaviour is unknown. This junit feature is
* "reloading classloader" behavior is unknown. This junit feature is
* intended for junit GUI apps where a test may be run multiple times
* within the same JVM - and in particular, when the .class file may
* be modified between runs of the test. How junit achieves this is

2
src/test/java/org/apache/commons/logging/pathable/ChildFirstTestCase.java
View File

@@ -256,7 +256,7 @@ public class ChildFirstTestCase extends TestCase {
// ClassLoader.getResources is final it isn't possible for PathableClassLoader
// to override this. So even when child-first is enabled the resource order
// is still (parent-resources, child-resources). This test verifies the expected
// behaviour - even though it's not the desired behaviour.
// behavior - even though it's not the desired behavior.
resources = childLoader.getResources("org/apache/commons/logging/impl/Log4JLogger.class");
urls = toURLArray(resources);

2
src/test/java/org/apache/commons/logging/security/SecurityAllowedTestCase.java
View File

@@ -35,7 +35,7 @@ import org.apache.commons.logging.PathableTestSuite;
/**
* Tests for logging with a security policy that allows JCL access to everything.
* <p>
* This class has only one unit test, as we are (in part) checking behaviour in
* This class has only one unit test, as we are (in part) checking behavior in
* the static block of the LogFactory class. As that class cannot be unloaded after
* being loaded into a classloader, the only workaround is to use the
* PathableClassLoader approach to ensure each test is run in its own

2
src/test/java/org/apache/commons/logging/security/SecurityForbiddenTestCase.java
View File

@@ -38,7 +38,7 @@ import org.apache.commons.logging.PathableTestSuite;
* messages on failure requires certain security permissions. If the security manager
* blocks these, then the test can fail without the error messages being output.
* <p>
* This class has only one unit test, as we are (in part) checking behaviour in
* This class has only one unit test, as we are (in part) checking behavior in
* the static block of the LogFactory class. As that class cannot be unloaded after
* being loaded into a classloader, the only workaround is to use the
* PathableClassLoader approach to ensure each test is run in its own