This class is specialized in retrieving loggers by name and also maintaining the logger hierarchy. The logger hierarchy is dealing with the several Log-Levels Logger can have. From log4j website:
"A logger is said to be an ancestor of another logger if its name followed by a dot is a prefix of the descendant logger name. A logger is said to be a parent of a child logger if there are no ancestors between itself and the descendant logger."
Child Loggers do inherit their Log-Levels from their Ancestors. They can increase their Log-Level compared to their Ancestors, but they cannot decrease it.
<p>The casual user does not have to deal with this class directly.</p>
<p>The structure of the logger hierarchy is maintained by the getLogger method. The hierarchy is such that children link to their parent but parents do not have any pointers to their children. Moreover, loggers can be instantiated in any order, in particular descendant before ancestor.</p>
<p>In case a descendant is created before a particular ancestor, then it creates a provision node for the ancestor and adds itself to the provision node. Other descendants of the same ancestor add themselves to the previously created provision node.</p>
Located in /LoggerHierarchy.php (line 56)
Create a new logger hierarchy.
This call will clear all logger definitions from the internal hashtable.
Check if the named logger exists in the hierarchy.
Returns all the currently defined categories in this hierarchy as an array.
Return a new logger instance named as the first parameter using the default factory.
This method will return true if this repository is disabled for level object passed as parameter and false otherwise.
Reset all values contained in this hierarchy instance to their default.
This removes all appenders from all categories, sets the level of all non-root categories to null, sets their additivity flag to true and sets the level of the root logger to LOGGER_LEVEL_DEBUG. Moreover, message disabling is set its default "off" value.
<p>Existing categories are not removed. They are just reset.
<p>This method should be used sparingly and with care as it will block all logging until it is completed.</p>
Shutting down a hierarchy will safely close and remove all appenders in all categories including the root logger.
Some appenders such as LoggerSocketAppender need to be closed before the application exists. Otherwise, pending logging events might be lost.
The shutdown method is careful to close nested appenders before closing regular appenders. This is allows configurations where a regular appender is attached to a logger and again to a nested appender.
Documentation generated on Fri, 27 Nov 2009 07:44:50 +0100 by phpDocumentor 1.4.3