The first abstraction is the LogKitManager:
public interface LogKitManager
{
Logger getLogger( String categoryName );
}
|
There is a implementation named DefaultLogKitManager
which is the only class exposed to clients. As a convenient a
additional interface is introduced for the
ComponentManager (stolen from the role management
system) which states that a class is willing to get a
LogKitManager:
public interface LogKitManageable
{
void setLogKitManager( LogKitManager logmanager );
}
|
This method has to be called before the configure method but after the
contextualize method.
The DefaultLogKitManager is Configurable
(as well as Loggable [the initial default logger] and
Contextualizable [to pass along for ie.
ServletOutputLogTarget]) and gets a
Configuration object as expressed in the logkit
xml syntax above. This DefaultLogKitManager then uses
a object of type
public interface LogTargetFactoryManager
{
LogTargetFactory getLogTargetFactory( String factoryName );
}
|
The DefaultLogTargetFactoryManager is
Configurable (as well as Loggable and
Contextualizable) and gets the
Configuration object located at the <factories>
element. It will instanciate the concrete factories into a map
keyed by the type attribute. So we are at the
LogTargetFactory abstraction which is:
public interface LogTargetFactory
{
LogTarget createTarget( Configuration configuration )
throws ConfigurationException;
}
|
It may happen that a LogTargetFactory needs to
create LogTargets they don't know in advance
and thus an additional interface is needed:
public interface LogTargetFactoryManageable
{
void setLogTargetFactoryManager( LogTargetFactoryManager logTargetFactoryManager );
}
|
This eases writing factories which acts like decorators
(AsyncLogTarget, PriorityFilter)
and thus need a LogTargetFactoryManager to create the decorated
LogTargets which are embeded in the configuration
of them (see <priority-filter> above).
After initializing the LogTargetFactoryManager a
LogTargetManager
public interface LogTargetManager
{
LogTarget getLogTarget( String targetId );
}
|
is created. The implementation DefaultLogTargetManager
is, you guess it, Configurable (as well as
Loggable and Contextualizable). The
Configuration object is the <targets> element
in the xml syntax and is put into a map keyed by the id
attribute of the target element. It is also
LogTargetFactoryManageable tob e able to create
the LogTargets.
The last step of the DefaultLogKitManagers configure
method is to create the actual categories based on the categories
elements content. It does it as the syntax will show in a
recursive way populating the Loggers retrieved by
Hierarchy.getDefaultHierarchy().getLoggerFor( full_category )
with the denoted LogTargets from the
LogTargetManager.
After that the LogKitManager is ready to be asked
for Loggers.
Now Avalon's Automated Component Management System is aware of a
"magic attributes" named logger and used like
logger="category" on the component definition syntax.
The classes building up Avalon's Automated Component Management System
are made LogTargetFactoryManageable. If you pass along
a LogKitManager to the ExcaliburComponentManager
the Component Management System will retrieve the denoted logger
category specified with the logger attribute from the
LogKitManager and pass it to Components
implementing Loggable.