Spelling in comments

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

@@ -121,7 +121,7 @@ public abstract class LogFactory {
      * The name ({@code org.apache.commons.logging.diagnostics.dest})
      * of the property used to enable internal commons-logging
      * diagnostic output, in order to get information on what logging
-     * implementations are being discovered, what classloaders they
+     * implementations are being discovered, what class loaders they
      * are loaded through, etc.
      * <p>
      * If a system property of this name is set then the value is
@@ -153,7 +153,7 @@ public abstract class LogFactory {
      * Setting this system property
      * ({@code org.apache.commons.logging.LogFactory.HashtableImpl})
      * value allows the {@code Hashtable} used to store
-     * classloaders to be substituted by an alternative implementation.
+     * class loaders to be substituted by an alternative implementation.
      * <p>
      * <strong>Note:</strong> {@code LogFactory} will print:
      * <pre>
@@ -178,7 +178,7 @@ public abstract class LogFactory {
      * <p>
      * A typical use case is to allow a custom
      * Hashtable implementation using weak references to be substituted.
-     * This will allow classloaders to be garbage collected without
+     * This will allow class loaders to be garbage collected without
      * the need to release them (on 1.3+ JVMs only, of course ;).
      */
     public static final String HASHTABLE_IMPLEMENTATION_PROPERTY =
@@ -337,7 +337,7 @@ public abstract class LogFactory {
                         msg.append("'. ");
                         if (implementsLogFactory) {
                             msg.append("The conflict is caused by the presence of multiple LogFactory classes ");
-                            msg.append("in incompatible classloaders. ");
+                            msg.append("in incompatible class loaders. ");
                             msg.append("Background can be found in http://commons.apache.org/logging/tech.html. ");
                             msg.append("If you have not explicitly specified a custom LogFactory then it is likely ");
                             msg.append("that the container has set one without your knowledge. ");
@@ -537,7 +537,7 @@ public abstract class LogFactory {
      * <p>
      * Even when using an AccessController, however, this method can still
      * throw SecurityException. Commons Logging basically relies on the
-     * ability to access classloaders. A policy that forbids all
+     * ability to access class loaders. A policy that forbids all
      * classloader access will also prevent commons-logging from working:
      * currently this method will throw an exception preventing the entire app
      * from starting up. Maybe it would be good to detect this situation and
@@ -1131,7 +1131,7 @@ public abstract class LogFactory {
                 // LogFactory cannot be loaded by the classloader which loaded the custom factory implementation.
                 // The custom implementation is not viable until this is corrected.
                 // Ensure that the JCL jar and the custom class are available from the same classloader.
-                // Running with diagnostics on should give information about the classloaders used
+                // Running with diagnostics on should give information about the class loaders used
                 // to load the custom factory.
                 //
                 logDiagnostic("[CUSTOM LOG FACTORY] LogFactory class cannot be loaded by the class loader which loaded "
@@ -1478,7 +1478,7 @@ public abstract class LogFactory {
      */
     public static void releaseAll() {
         if (isDiagnosticsEnabled()) {
-            logDiagnostic("Releasing factory for all classloaders.");
+            logDiagnostic("Releasing factory for all class loaders.");
         }
         // factories is not final and could be replaced in this block.
         final Hashtable<ClassLoader, LogFactory> factories = LogFactory.factories;
@@ -1601,7 +1601,7 @@ public abstract class LogFactory {
         final ClassLoader thisClassLoader = getClassLoader(LogFactory.class);
         thisClassLoaderRef = new WeakReference<>(thisClassLoader);
         // In order to avoid confusion where multiple instances of JCL are
-        // being used via different classloaders within the same app, we
+        // being used via different class loaders within the same app, we
         // ensure each logged message has a prefix of form
         // [LogFactory from classloader OID]
         //

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

@@ -102,7 +102,7 @@ public class LogFactoryImpl extends LogFactory {
      * LogFactoryImpl is loaded via a child classloader of the TCCL (this
      * should never happen in sane systems).
      *
-     * Default behavior: true (tolerates bad context classloaders)
+     * Default behavior: true (tolerates bad context class loaders)
      *
      * See also method setAttribute.
      */
@@ -543,7 +543,7 @@ public class LogFactoryImpl extends LogFactory {
         //
         // Note that we deliberately loop here over classesToDiscover and
         // expect method createLogFromClass to loop over the possible source
-        // classloaders. The effect is:
+        // class loaders. The effect is:
         //   for each discoverable log adapter
         //      for each possible classloader
         //          see if it works
@@ -679,7 +679,7 @@ public class LogFactoryImpl extends LogFactory {
      * <p>
      * The only time when the classloader which loaded this class is a
      * descendant (rather than the same as or an ancestor of the context
-     * classloader) is when an app has created custom classloaders but
+     * classloader) is when an app has created custom class loaders but
      * failed to correctly set the context classloader. This is a bug in
      * the calling application; however we provide the option for JCL to
      * simply generate a warning rather than fail outright.
@@ -698,7 +698,7 @@ public class LogFactoryImpl extends LogFactory {
                 contextClassLoader, thisClassLoader);
 
         if (baseClassLoader == null) {
-           // The two classloaders are not part of a parent child relationship.
+           // The two class loaders are not part of a parent child relationship.
            // In some classloading setups (e.g. JBoss with its
            // UnifiedLoaderRepository) this can still work, so if user hasn't
            // forbidden it, just return the contextClassLoader.
@@ -722,7 +722,7 @@ public class LogFactoryImpl extends LogFactory {
             // We really should just use the contextClassLoader as the starting
             // point for scanning for log adapter classes. However it is expected
             // that there are a number of broken systems out there which create
-            // custom classloaders but fail to set the context classloader so
+            // custom class loaders but fail to set the context classloader so
             // we handle those flawed systems anyway.
             if (!allowFlawedContext) {
                 throw new LogConfigurationException(
@@ -895,7 +895,7 @@ public class LogFactoryImpl extends LogFactory {
     //  ------------------------------------------------------ Private Methods
 
     /**
-     * Given two related classloaders, return the one which is a child of
+     * Given two related class loaders, return the one which is a child of
      * the other.
      * <p>
      * @param c1 is a classloader (including the null classloader)
@@ -905,7 +905,7 @@ public class LogFactoryImpl extends LogFactory {
      * and null if neither is an ancestor of the other.
      */
     private ClassLoader getLowestClassLoader(final ClassLoader c1, final ClassLoader c2) {
-        // TODO: use AccessController when dealing with classloaders here
+        // TODO: use AccessController when dealing with class loaders here
 
         if (c1 == null) {
             return c2;

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

@@ -33,7 +33,7 @@ import org.apache.commons.logging.LogFactory;
  * In general, the WeakHashtable support added in commons-logging release 1.1
  * ensures that logging classes do not hold references that prevent an
  * undeployed webapp's memory from being garbage-collected even when multiple
- * copies of commons-logging are deployed via multiple classloaders (a
+ * copies of commons-logging are deployed via multiple class loaders (a
  * situation that earlier versions had problems with). However there are
  * some rare cases where the WeakHashtable approach does not work; in these
  * situations specifying this class as a listener for the web application will
@@ -62,7 +62,7 @@ public class ServletContextCleaner implements ServletContextListener {
         final Object[] params = new Object[1];
         params[0] = tccl;
 
-        // Walk up the tree of classloaders, finding all the available
+        // Walk up the tree of class loaders, finding all the available
         // LogFactory classes and releasing any objects associated with
         // the tccl (ie the webapp).
         //
@@ -87,7 +87,7 @@ public class ServletContextCleaner implements ServletContextListener {
         // to is expected to have been loaded via the TCCL, so the
         // underlying logging lib is only initialized/configured once.
         // These references from ancestor LogFactory classes down to
-        // TCCL classloaders are held via weak references and so should
+        // TCCL class loaders are held via weak references and so should
         // be released but there are circumstances where they may not.
         // Walking up the classloader ancestry ladder releasing
         // the current tccl at each level tree, though, will definitely

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

@@ -47,7 +47,7 @@ import java.util.Set;
  * <strong>Usage:</strong> typical use case is as a drop-in replacement
  * for the {@code Hashtable} used in {@code LogFactory} for J2EE environments
  * running 1.3+ JVMs. Use of this class <i>in most cases</i> (see below) will
- * allow classloaders to be collected by the garbage collector without the need
+ * allow class loaders to be collected by the garbage collector without the need
  * to call {@link org.apache.commons.logging.LogFactory#release(ClassLoader) LogFactory.release(ClassLoader)}.
  * <p>
  * {@code org.apache.commons.logging.LogFactory} checks whether this class
@@ -64,7 +64,7 @@ import java.util.Set;
  * <p>
  * The reason all this is necessary is due to a issue which
  * arises during hot deploy in a J2EE-like containers.
- * Each component running in the container owns one or more classloaders; when
+ * Each component running in the container owns one or more class loaders; when
  * the component loads a LogFactory instance via the component classloader
  * a reference to it gets stored in the static LogFactory.factories member,
  * keyed by the component's classloader so different components don't
@@ -73,7 +73,7 @@ import java.util.Set;
  * component's classes get garbage-collected. However there's still a
  * reference to the component's classloader from a key in the "global"
  * {@code LogFactory}'s factories member! If {@code LogFactory.release()}
- * is called whenever component is unloaded, the classloaders will be correctly
+ * is called whenever component is unloaded, the class loaders will be correctly
  * garbage collected; this <i>should</i> be done by any container that
  * bundles commons-logging by default. However, holding the classloader
  * references weakly ensures that the classloader will be garbage collected

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

@@ -348,7 +348,7 @@ public class PathableClassLoader extends URLClassLoader {
      * Checking with the parent first is the normal approach for java, but
      * components within containers such as servlet engines can use
      * child-first lookup instead, to allow the components to override libs
-     * which are visible in shared classloaders provided by the container.
+     * which are visible in shared class loaders provided by the container.
      * <p>
      * Note that the method getResources always behaves as if parentFirst=true,
      * because of limitations in java 1.4; see the javadoc for method
@@ -393,15 +393,15 @@ public class PathableClassLoader extends URLClassLoader {
      * <ul>
      * <li>If code calls getClassLoader on a class loaded via
      * "lookaside", then traces up its inheritance chain, it
-     * will see the "real" classloaders. When the class is remapped
+     * will see the "real" class loaders. When the class is remapped
      * into this classloader via addLogicalLib, the classloader
      * chain seen is this object plus ancestors.
      * <li>If two different jars contain classes in the same
      * package, then it is not possible to load both jars into
      * the same "lookaside" classloader (eg the system classloader)
      * then map one of those subsets from here. Of course they could
-     * be loaded into two different "lookaside" classloaders and
+     * be loaded into two different "lookaside" class loaders and
-     * then a prefix used to map from here to one of those classloaders.
+     * then a prefix used to map from here to one of those class loaders.
      * </ul>
      */
     public void useExplicitLoader(final String prefix, final ClassLoader loader) {

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

@@ -58,7 +58,7 @@ import junit.framework.TestSuite;
  * <p>
  * This class will run each test methods within the specified TestCase using
  * the specified context classloader and system classloader. If different
- * tests within the same class require different context classloaders,
+ * tests within the same class require different context class loaders,
  * then the context classloader passed to the constructor should be the
  * "lowest" one available, and tests that need the context set to some parent
  * of this "lowest" classloader can call
@@ -81,7 +81,7 @@ import junit.framework.TestSuite;
  * is different from the class whose suite() method was executed to determine
  * the classpath. This means that the suite method cannot communicate with
  * the test cases simply by setting static variables (for example to make the
- * custom classloaders available to the test methods or setUp/tearDown fixtures).
+ * custom class loaders available to the test methods or setUp/tearDown fixtures).
  * If this is really necessary then it is possible to use reflection to invoke
  * static methods on the class object passed to the constructor of this class.
  * <p>

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

@@ -107,7 +107,7 @@ public class ChildFirstTestCase extends TestCase {
     }
 
     /**
-     * Utility method to return the set of all classloaders in the
+     * Utility method to return the set of all class loaders in the
      * parent chain starting from the one that loaded the class for
      * this object instance.
      */
@@ -123,7 +123,7 @@ public class ChildFirstTestCase extends TestCase {
 
     /**
      * Test that the classloader hierarchy is as expected, and that
-     * calling loadClass() on various classloaders works as expected.
+     * calling loadClass() on various class loaders works as expected.
      * Note that for this test case, parent-first classloading is
      * in effect.
      */
@@ -167,7 +167,7 @@ public class ChildFirstTestCase extends TestCase {
                         systemLoader.getClass().getName()));
 
         // junit classes should be visible; their classloader is not
-        // in the hierarchy of parent classloaders for this class,
+        // in the hierarchy of parent class loaders for this class,
         // though it is accessible due to trickery in the PathableClassLoader.
         final Class junitTest = contextLoader.loadClass("junit.framework.Test");
         final Set ancestorCLs = getAncestorCLs();
@@ -180,7 +180,7 @@ public class ChildFirstTestCase extends TestCase {
                 logClass.getClassLoader(), parentLoader);
 
         // jcl adapter classes should be visible via both parent and child. However
-        // as the classloaders are child-first we should see the child one.
+        // as the class loaders are child-first we should see the child one.
         final Class log4jClass = contextLoader.loadClass("org.apache.commons.logging.impl.Log4JLogger");
         assertSame("Log4JLogger not loaded via child",
                 log4jClass.getClassLoader(), thisLoader);
@@ -226,7 +226,7 @@ public class ChildFirstTestCase extends TestCase {
         resource = childLoader.getResource("org/apache/commons/logging/PathableTestSuite.class");
         assertNotNull("Unable to locate PathableTestSuite.class resource", resource);
 
-        // getResource where it is accessible to both classloaders. The one visible
+        // getResource where it is accessible to both class loaders. The one visible
         // to the child should be returned. The URL returned will be of form
         //  jar:file:/x/y.jar!path/to/resource. The file name part should include the jarname
         // of form commons-logging-adapters-nnnn.jar, not commons-logging-nnnn.jar

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

@@ -105,7 +105,7 @@ public class ParentFirstTestCase extends TestCase {
     }
 
     /**
-     * Utility method to return the set of all classloaders in the
+     * Utility method to return the set of all class loaders in the
      * parent chain starting from the one that loaded the class for
      * this object instance.
      */
@@ -121,7 +121,7 @@ public class ParentFirstTestCase extends TestCase {
 
     /**
      * Test that the classloader hierarchy is as expected, and that
-     * calling loadClass() on various classloaders works as expected.
+     * calling loadClass() on various class loaders works as expected.
      * Note that for this test case, parent-first classloading is
      * in effect.
      */
@@ -164,7 +164,7 @@ public class ParentFirstTestCase extends TestCase {
                 systemLoader.getClass().getName());
 
         // junit classes should be visible; their classloader is not
-        // in the hierarchy of parent classloaders for this class,
+        // in the hierarchy of parent class loaders for this class,
         // though it is accessible due to trickery in the PathableClassLoader.
         final Class junitTest = contextLoader.loadClass("junit.framework.Test");
         final Set ancestorCLs = getAncestorCLs();
@@ -177,7 +177,7 @@ public class ParentFirstTestCase extends TestCase {
                 logClass.getClassLoader(), parentLoader);
 
         // jcl adapter classes should be visible via both parent and child. However
-        // as the classloaders are parent-first we should see the parent one.
+        // as the class loaders are parent-first we should see the parent one.
         final Class log4jClass = contextLoader.loadClass("org.apache.commons.logging.impl.Log4JLogger");
         assertSame("Log4JLogger not loaded via parent",
                 log4jClass.getClassLoader(), parentLoader);
@@ -223,7 +223,7 @@ public class ParentFirstTestCase extends TestCase {
         resource = childLoader.getResource("org/apache/commons/logging/PathableTestSuite.class");
         assertNotNull("Unable to locate PathableTestSuite.class resource", resource);
 
-        // getResource where it is accessible to both classloaders. The one visible
+        // getResource where it is accessible to both class loaders. The one visible
         // to the parent should be returned. The URL returned will be of form
         //  jar:file:/x/y.jar!path/to/resource. The file name part should include the jarname
         // of form commons-logging-nnnn.jar, not commons-logging-adapters-nnnn.jar