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 LogTarget
s 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 Logger
s.
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 Component
s
implementing Loggable
.