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

Spelling in comments

Browse Source
This commit is contained in:
Gary Gregory
2023-11-20 09:58:59 -05:00
parent 51a3978280
commit 6b11d8ab2e
8 changed files with 37 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

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

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

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

6
src/main/java/org/apache/commons/logging/impl/ServletContextCleaner.java
View File

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

6
src/main/java/org/apache/commons/logging/impl/WeakHashtable.java
View File

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