1.1.1
Factory for creating Log
IMPLEMENTATION NOTE - This implementation is heavily based on the SAXParserFactory and DocumentBuilderFactory implementations (corresponding to the JAXP pluggability APIs) found in Apache Xerces.
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
are loaded through, etc.
If a system property of this name is set then the value is assumed to be the name of a file. The special strings STDOUT or STDERR (case-sensitive) indicate output to System.out and System.err respectively.
Diagnostic logging should be used only to debug problematic configurations and should not be set in normal production use.
Setting this system property
(org.apache.commons.logging.LogFactory.HashtableImpl)
value allows the Hashtable used to store
classloaders to be substituted by an alternative implementation.
Note: LogFactory will print:
[ERROR] LogFactory: Load of custom hashtable failedto system error and then continue using a standard Hashtable.
Usage: Set this property when Java is invoked
and LogFactory will attempt to load a new instance
of the given implementation class.
For example, running the following ant scriplet:
<java classname="${test.runner}" fork="yes" failonerror="${test.failonerror}">
...
<sysproperty
key="org.apache.commons.logging.LogFactory.HashtableImpl"
value="org.apache.commons.logging.AltHashtable"/>
</java>
will mean that LogFactory will load an instance of
org.apache.commons.logging.AltHashtable.
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 the need to release them (on 1.3+ JVMs only, of course ;)
getInstance(String) with it.
clazz Class for which a suitable Log name will be derivedLogConfigurationException if a suitable Log
instance cannot be returnedConstruct (if necessary) and return a Log instance,
using the factory's current set of configuration attributes.
NOTE - Depending upon the implementation of
the LogFactory you are using, the Log
instance you are returned may or may not be local to the current
application, and may or may not be returned again on a subsequent
call with the same name argument.
name Logical name of the Log instance to be
returned (the meaning of this name is only known to the underlying
logging implementation that is being wrapped)LogConfigurationException if a suitable Log
instance cannot be returnedLogLogFactory instance as in the
factories map, but for the case where
getClassLoader returns null.
This can happen when:
factories is a Hashtable (not a HashMap),
and hashtables don't allow null as a key.
Note that the correct way to ensure no memory leaks occur is to ensure that LogFactory.release(contextClassLoader) is called whenever a webapp is undeployed.
Construct (if necessary) and return a LogFactory
instance, using the following ordered lookup procedure to determine
the name of the implementation class to be loaded.
org.apache.commons.logging.LogFactory system
property.commons-logging.properties
file, if found in the class path of this class. The configuration
file is in standard java.util.Properties format and
contains the fully qualified name of the implementation class
with the key being the system property defined above.org.apache.commons.logging.impl.LogFactoryImpl).NOTE - If the properties file method of identifying the
LogFactory implementation class is utilized, all of the
properties defined in this file will be set as configuration attributes
on the corresponding LogFactory instance.
NOTE - In a multithreaded environment it is possible that two different instances will be returned for the same classloader environment.
LogConfigurationException if the implementation class is not
available or cannot be instantiated.clazz Class from which a log name will be derivedLogConfigurationException if a suitable Log
instance cannot be returnedname Logical name of the Log instance to be
returned (the meaning of this name is only known to the underlying
logging implementation that is being wrapped)LogConfigurationException if a suitable Log
instance cannot be returnedLogFactoryrelease() on
each of them.
classLoader ClassLoader for which to release the LogFactoryLogFactoryrelease() on
each of them. This is useful in environments like servlet containers,
which implement application reloading by throwing away a ClassLoader.
Dangling references to objects in that class loader would prevent
garbage collection.
Theoretically, calling getClassLoader can throw a security exception, and so should be done under an AccessController in order to provide maximum flexibility. However in practice people don't appear to use security policies that forbid getClassLoader calls. So for the moment all code is written to call this method rather than Class.getClassLoader, so that we could put AccessController stuff in this method without any disruption later if we need to.
Even when using an AccessController, however, this method can still throw SecurityException. Commons-logging basically relies on the ability to access classloaders, ie 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 just disable all commons-logging? Not high priority though - as stated above, security policies that prevent classloader access aren't common.
Note that returning an object fetched via an AccessController would technically be a security flaw anyway; untrusted code that has access to a trusted JCL library could use it to fetch the classloader for a class even when forbidden to do so directly.
In versions prior to 1.1, this method did not use an AccessController. In version 1.1, an AccessController wrapper was incorrectly added to this method, causing a minor security flaw.
In version 1.1.1 this change was reverted; this method no longer uses an AccessController. User code wishing to obtain the context classloader must invoke this method via AccessController.doPrivileged if it needs support for that.
LogConfigurationException if there was some weird error while
attempting to get the context classloader.java.lang.SecurityException if the current java security policy doesn't
allow this class to access the context classloader.LogConfigurationException if there was some weird error while
attempting to get the context classloader.java.lang.SecurityException if the current java security policy doesn't
allow this class to access the context classloader.Most/all code should call getContextClassLoaderInternal rather than calling this method directly.
The thread context class loader is available for JDK 1.2 or later, if certain security conditions are met.
Note that no internal logging is done within this method because this method is called every time LogFactory.getLogger() is called, and we don't want too much output generated here.
LogConfigurationException if a suitable class loader
cannot be identified.java.lang.SecurityException if the java security policy forbids
access to the context classloader from one of the classes in the
current call stack.contextClassLoader is the context classloader associated
with the current thread. This allows separate LogFactory objects
per component within a container, provided each component has
a distinct context classloader set. This parameter may be null
in JDK1.1, and in embedded systems where jcl-using code is
placed in the bootclasspath.classLoader should be the current context classloader. Note that
this can be null under some circumstances; this is ok.factory should be the factory to cache. This should never be null.LogFactory
implementation class, loaded by the specified class loader.
If that fails, try the class loader used to load this
(abstract) LogFactory.
The problem is the same one that can occur when loading a concrete Log subclass via a context classloader.
The problem occurs when code running in the context classloader calls class X which was loaded via a parent classloader, and class X then calls LogFactory.getFactory (either directly or via LogFactory.getLog). Because class X was loaded via the parent, it binds to LogFactory loaded via the parent. When the code in this method finds some LogFactoryYYYY class in the child (context) classloader, and there also happens to be a LogFactory class defined in the child classloader, then LogFactoryYYYY will be bound to LogFactory@childloader. It cannot be cast to LogFactory@parentloader, ie this method cannot return the object as the desired type. Note that it doesn't matter if the LogFactory class in the child classloader is identical to the LogFactory class in the parent classloader, they are not compatible.
The solution taken here is to simply print out an error message when this occurs then throw an exception. The deployer of the application must ensure they remove all occurrences of the LogFactory class from the child classloader in order to resolve the issue. Note that they do not have to move the custom LogFactory subclass; that is ok as long as the only LogFactory class it can find to bind to is in the parent classloader.
factoryClass Fully qualified name of the LogFactory
implementation classclassLoader ClassLoader from which to load this classcontextClassLoader is the context that this new factory will
manage logging for.LogConfigurationException if a suitable instance
cannot be createdThis method would only ever be called in some rather odd situation. Note that this method is static, so overriding in a subclass doesn't have any effect unless this method is called from a method in that subclass. However this method only makes sense to use from the getFactory method, and as that is almost always invoked via LogFactory.getFactory, any custom definition in a subclass would be pointless. Only a class with a custom getFactory method, then invoked directly via CustomFactoryImpl.getFactory or similar would ever call this. Anyway, it's here just in case, though the "managed class loader" value output to the diagnostics will not report the correct value.
factoryClassclassLoader used to load the specified factory class. This is
expected to be either the TCCL or the classloader which loaded this
class. Note that the classloader which loaded this class might be
"null" (ie the bootloader) for embedded systems.msg = msg + "The conflict is caused by the presence of multiple LogFactory classes in incompatible classloaders. " +
LogFactory.
Diagnostic information is also logged.
Usage: to diagnose whether a classloader conflict is the cause
of incompatibility. The test used is whether the class is assignable from
the LogFactory class loaded by the class's classloader.
logFactoryClass Class which may implement LogFactorylogFactoryClass does extend
LogFactory when that class is loaded via the same
classloader that loaded the logFactoryClass. // LogFactory cannot be loaded by the classloader which loaded the custom factory implementation.logDiagnostic("[CUSTOM LOG FACTORY] LogFactory class cannot be loaded by classloader which loaded the " +
This is just like ClassLoader.getResources except that the operation is done under an AccessController so that this method will succeed when this jarfile is privileged but the caller is not. This method must therefore remain private to avoid security issues.
If no instances are found, an Enumeration is returned whose hasMoreElements method returns false (ie an "empty" enumeration). If resources could not be listed for some reason, null is returned.
Null is returned if the URL cannot be opened.
The classpath of the specified classLoader (usually the context classloader) is searched for properties files of the specified name. If none is found, null is returned. If more than one is found, then the file with the greatest value for its PRIORITY property is returned. If multiple files have the same PRIORITY value then the first in the classpath is returned.
This differs from the 1.0.x releases; those always use the first one found. However as the priority is a new field, this change is backwards compatible.
The purpose of the priority field is to allow a webserver administrator to override logging settings in all webapps by placing a commons-logging.properties file in a shared classpath location with a priority > 0; this overrides any commons-logging.properties files without priorities which are in the webapps. Webapps can also use explicit priorities to override a configuration file in the shared classpath if needed.
Take care not to expose the value returned by this method to the calling application in any way; otherwise the calling app can use that info to access data that should not be available to it.
DIAGNOSTICS_DEST_PROPERTYNote that this method is private; concrete subclasses of this class should not call it because the diagnosticPrefix string this method puts in front of all its messages is LogFactory@...., while subclasses should put SomeSubClass@...
Subclasses should instead compute their own prefix, then call logRawDiagnostic. Note that calling isDiagnosticsEnabled is fine for subclasses.
Note that it is safe to call this method before initDiagnostics is called; any output will just be ignored (as isDiagnosticsEnabled will return false).
msg is the diagnostic message to be output.As an example, if the specified class was loaded via a webapp's classloader, then you may get the following output:
Class com.acme.Foo was loaded via classloader 11111 ClassLoader tree: 11111 -> 22222 (SYSTEM) -> 33333 -> BOOT
This method returns immediately if isDiagnosticsEnabled() returns false.
clazz is the class whose classloader + tree are to be
output.logDiagnostic("[ENV] Application classpath (java.class.path): " + System.getProperty("java.class.path"));
The returned string is of form "classname@hashcode", ie is the same as the return value of the Object.toString() method, but works even when the specified object's class has overidden the toString method.
o may be null.