Java Doc for LogFactory.java in  » Library » apache-common-Logging » org » apache » commons » logging » Java Source Code / Java DocumentationJava Source Code and Java Documentation

Factory for creating Log instances, with discovery and configuration features similar to that employed by standard Java APIs such as JAXP.

IMPLEMENTATION NOTE - This implementation is heavily based on the SAXParserFactory and DocumentBuilderFactory implementations (corresponding to the JAXP pluggability APIs) found in Apache Xerces.

If a system property of this name is set then the value is assumed to be the name of a file.

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.

Theoretically, calling getClassLoader can throw a security exception, and so should be done under an AccessController in order to provide maximum flexibility.

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.

• The org.apache.commons.logging.LogFactory system property.
• The JDK 1.3 Service Discovery mechanism
• Use the properties file commons-logging.properties file, if found in the class path of this class.

ClassLoader conflicts

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).

This 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.

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.
Parameters:
  o - may be null.

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 failed
 

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>
 

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

• using JDK1.1 and the calling code is loaded via the system classloader (very common)
• using JDK1.2+ and the calling code is loaded via the boot classloader (only likely for embedded systems work).

Most/all code should call getContextClassLoader 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.
exception:
  LogConfigurationException - if a suitable class loadercannot be identified.
exception:
  SecurityException - if the java security policy forbidsaccess to the context classloader from one of the classes in thecurrent call stack.
since:
   1.1

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.
since:
   1.1

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.

• The org.apache.commons.logging.LogFactory system property.
• The JDK 1.3 Service Discovery mechanism
• Use the properties file 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.
• Fall back to a default implementation class (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.

Construct (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.

By the way, sorry for the incorrect grammar, but calling this method areDiagnosticsEnabled just isn't java beans style. true if calls to logDiagnostic will have any effect.
since:
   1.1

ClassLoader conflicts

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.

Parameters:
  factoryClass - Fully qualified name of the LogFactoryimplementation class
Parameters:
  classLoader - ClassLoader from which to load this class
Parameters:
  contextClassLoader - is the context that this new factory willmanage logging for.
exception:
  LogConfigurationException - if a suitable instancecannot be created
since:
   1.1

This 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.

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.
Parameters:
  o - may be null. a string of form classname@hashcode, or "null" if param o is null.
since:
   1.1