Standardize on American English spelling of 'behavior'.

build-testing.xml

@@ -290,7 +290,7 @@
 
       <echo message="executing tests [${testmatch}.java]"/>
     <!--
-      - Note that the fork/forkmode settings define default behaviour for tests. 
+      - Note that the fork/forkmode settings define default behavior for tests. 
       - The <test> and <batchtest> tags can override these settings if needed.
       - The default settings cause a single VM to be created in which all of
       - the tests are then run. 

build.xml

@@ -727,7 +727,7 @@
 
     <echo message="executing tests [${testmatch}.java]"/>
     <!--
-      - Note that the fork/forkmode settings define default behaviour for tests. 
+      - Note that the fork/forkmode settings define default behavior for tests. 
       - The <test> and <batchtest> tags can override these settings if needed.
       - The default settings cause a single VM to be created in which all of
       - the tests are then run. 

src/main/java/org/apache/commons/logging/LogFactory.java

@@ -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);

src/main/java/org/apache/commons/logging/impl/LogFactoryImpl.java

@@ -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.

src/site/xdoc/junit-report.xml

@@ -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>.

src/site/xdoc/tech.xml

@@ -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>

src/site/xdoc/troubleshooting.xml

@@ -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.

src/test/java/org/apache/commons/logging/BadHashtablePropertyTestCase.java

@@ -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 {
 

src/test/java/org/apache/commons/logging/PathableTestSuite.java

@@ -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

src/test/java/org/apache/commons/logging/pathable/ChildFirstTestCase.java

@@ -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);

src/test/java/org/apache/commons/logging/security/SecurityAllowedTestCase.java

@@ -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

src/test/java/org/apache/commons/logging/security/SecurityForbiddenTestCase.java

@@ -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