java.lang.ObjectModified LogFactory: removed all discovery, hardcode a specific implementation If you like a different logging implementation - use either the discovery-based commons-logging, or better - another implementation hardcoded to your favourite logging impl. Why ? Each application and deployment can choose a logging implementation - that involves configuration, installing the logger jar and optional plugins, etc. As part of this process - they can as well install the commons-logging implementation that corresponds to their logger of choice. This completely avoids any discovery problem, while still allowing the user to switch. Note that this implementation is not just a wrapper arround JDK logging ( like the original commons-logging impl ). It adds 2 features - a simpler configuration ( which is in fact a subset of log4j.properties ) and a formatter that is less ugly. The removal of 'abstract' preserves binary backward compatibility. It is possible to preserve the abstract - and introduce another ( hardcoded ) factory - but I see no benefit. Since this class is not intended to be extended - and provides no plugin for other LogFactory implementation - all protected methods are removed. This can be changed - but again, there is little value in keeping dead code. Just take a quick look at the removed code ( and it's complexity) -------------- Original comment:org.apache.juli.logging.LogFactory
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.
Craig - R. McClanahanCostin - ManolacheRichard - A. Sitze$ - Revision: 467222 $ $Date: 2006-10-24 05:17:11 +0200 (mar., 24 oct. 2006) $| Field Summary | ||
|---|---|---|
| public static final String | FACTORY_PROPERTY | The name of the property used to identify the LogFactory implementation class name. |
| public static final String | FACTORY_DEFAULT | The fully qualified class name of the fallback LogFactory
implementation class to use, if no other can be found. |
| public static final String | FACTORY_PROPERTIES | The name of the properties file to search for. |
| public static final String | HASHTABLE_IMPLEMENTATION_PROPERTY | Setting this system property value allows the
Note:
Usage: Set this property when Java is invoked
and 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 ;) |
| Properties | logConfig | |
| Method from org.apache.juli.logging.LogFactory Summary: |
|---|
| getAttribute, getAttributeNames, getFactory, getInstance, getInstance, getLog, getLog, objectId, release, release, releaseAll, removeAttribute, setAttribute, setLogConfig |
| Methods from java.lang.Object: |
|---|
| equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Method from org.apache.juli.logging.LogFactory Detail: |
|---|
null if there is no such attribute. |
|
Construct (if necessary) and return a NOTE - If the properties file method of identifying the
|
Construct (if necessary) and return a NOTE - Depending upon the implementation of
the |
getInstance(String) with it. |
|
|
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. |
|
release() on
each of them. |
release() 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. |
|
null value is equivalent to calling
removeAttribute(name). |
|