* 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. *
* Note: {@code LogFactory} will print: *
@@ -178,7 +178,7 @@ public abstract class LogFactory {
*
* 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 {
*
* 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 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]
//
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 da9482e..7bdf7e2 100644
--- a/src/main/java/org/apache/commons/logging/impl/LogFactoryImpl.java
+++ b/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 {
*
* 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.
*
* @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;
diff --git a/src/main/java/org/apache/commons/logging/impl/ServletContextCleaner.java b/src/main/java/org/apache/commons/logging/impl/ServletContextCleaner.java
index 7c1137d..b0fc41d 100644
--- a/src/main/java/org/apache/commons/logging/impl/ServletContextCleaner.java
+++ b/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
diff --git a/src/main/java/org/apache/commons/logging/impl/WeakHashtable.java b/src/main/java/org/apache/commons/logging/impl/WeakHashtable.java
index a2111b0..bb053ac 100644
--- a/src/main/java/org/apache/commons/logging/impl/WeakHashtable.java
+++ b/src/main/java/org/apache/commons/logging/impl/WeakHashtable.java
@@ -47,7 +47,7 @@ import java.util.Set;
* Usage: 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 in most cases (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)}.
*
* {@code org.apache.commons.logging.LogFactory} checks whether this class
@@ -64,7 +64,7 @@ import java.util.Set;
*
* 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 should 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
diff --git a/src/test/java/org/apache/commons/logging/PathableClassLoader.java b/src/test/java/org/apache/commons/logging/PathableClassLoader.java
index 7dbdb78..03e04b0 100644
--- a/src/test/java/org/apache/commons/logging/PathableClassLoader.java
+++ b/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.
*
* 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 {
*
* - 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.
*
- 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
- * then a prefix used to map from here to one of those classloaders.
+ * be loaded into two different "lookaside" class loaders and
+ * then a prefix used to map from here to one of those class loaders.
*
*/
public void useExplicitLoader(final String prefix, final ClassLoader loader) {
diff --git a/src/test/java/org/apache/commons/logging/PathableTestSuite.java b/src/test/java/org/apache/commons/logging/PathableTestSuite.java
index 1024513..fd414a6 100644
--- a/src/test/java/org/apache/commons/logging/PathableTestSuite.java
+++ b/src/test/java/org/apache/commons/logging/PathableTestSuite.java
@@ -58,7 +58,7 @@ import junit.framework.TestSuite;
*
* 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.
*
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 37cd2a6..e5a367a 100644
--- a/src/test/java/org/apache/commons/logging/pathable/ChildFirstTestCase.java
+++ b/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
diff --git a/src/test/java/org/apache/commons/logging/pathable/ParentFirstTestCase.java b/src/test/java/org/apache/commons/logging/pathable/ParentFirstTestCase.java
index 427d45c..836e361 100644
--- a/src/test/java/org/apache/commons/logging/pathable/ParentFirstTestCase.java
+++ b/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