diff --git a/build-testing.xml b/build-testing.xml
index 17ad984..ecc8bb1 100644
--- a/build-testing.xml
+++ b/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. 
diff --git a/build.xml b/build.xml
index 8055c58..6012a84 100644
--- a/build.xml
+++ b/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. 
diff --git a/src/main/java/org/apache/commons/logging/LogFactory.java b/src/main/java/org/apache/commons/logging/LogFactory.java
index e172820..f3e0d24 100644
--- a/src/main/java/org/apache/commons/logging/LogFactory.java
+++ b/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);
diff --git a/src/main/java/org/apache/commons/logging/impl/LogFactoryImpl.java b/src/main/java/org/apache/commons/logging/impl/LogFactoryImpl.java
index 30fbdf5..0d0adb6 100644
--- a/src/main/java/org/apache/commons/logging/impl/LogFactoryImpl.java
+++ b/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.
diff --git a/src/site/xdoc/junit-report.xml b/src/site/xdoc/junit-report.xml
index 786c93c..f48dcd9 100644
--- a/src/site/xdoc/junit-report.xml
+++ b/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>.
diff --git a/src/site/xdoc/tech.xml b/src/site/xdoc/tech.xml
index 119bdf9..581ff05 100644
--- a/src/site/xdoc/tech.xml
+++ b/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>
diff --git a/src/site/xdoc/troubleshooting.xml b/src/site/xdoc/troubleshooting.xml
index 7ebe48a..d0ecbec 100644
--- a/src/site/xdoc/troubleshooting.xml
+++ b/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.
diff --git a/src/test/java/org/apache/commons/logging/BadHashtablePropertyTestCase.java b/src/test/java/org/apache/commons/logging/BadHashtablePropertyTestCase.java
index eda6e3f..967e426 100644
--- a/src/test/java/org/apache/commons/logging/BadHashtablePropertyTestCase.java
+++ b/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 {
 
diff --git a/src/test/java/org/apache/commons/logging/PathableTestSuite.java b/src/test/java/org/apache/commons/logging/PathableTestSuite.java
index 1a2ca81..3a71676 100644
--- a/src/test/java/org/apache/commons/logging/PathableTestSuite.java
+++ b/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
diff --git a/src/test/java/org/apache/commons/logging/pathable/ChildFirstTestCase.java b/src/test/java/org/apache/commons/logging/pathable/ChildFirstTestCase.java
index 1aeb12d..b49ebc1 100644
--- a/src/test/java/org/apache/commons/logging/pathable/ChildFirstTestCase.java
+++ b/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);
diff --git a/src/test/java/org/apache/commons/logging/security/SecurityAllowedTestCase.java b/src/test/java/org/apache/commons/logging/security/SecurityAllowedTestCase.java
index b957237..ccb88b3 100644
--- a/src/test/java/org/apache/commons/logging/security/SecurityAllowedTestCase.java
+++ b/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
diff --git a/src/test/java/org/apache/commons/logging/security/SecurityForbiddenTestCase.java b/src/test/java/org/apache/commons/logging/security/SecurityForbiddenTestCase.java
index 08c5af9..d8071d4 100644
--- a/src/test/java/org/apache/commons/logging/security/SecurityForbiddenTestCase.java
+++ b/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