It is assumed that the reader is familiar with the concepts found in
commons-digester. See http://jakarta.apache.org/commons/digester.html
for more details.
Log4j, or more specifically the DOMConfigurator, can parse and
interpret configuration files written in XML. One can define appenders
and their layouts, add these to loggers, set the level of loggers and
so on. Unfortunately, the DOMConfigurator cannot deal with XML tags
that were not known to it at compile time.
A jakarta-commons project called commons-digester offers a very
interesting method for interpreting XML files. Instead of hard coding
the way XML files are interpreted, one programs the digester with a
set of rules (a pattern+an action). When the given pattern is matched
by the XML element being parsed, then the programmed action or actions
are invoked. Beside increased clarity and modularity of the code, the
digester mechanism opens the door for dynamic configuration, that is
the capability to learn new rules at run time, much like ANT's ability
to learn new tasks.
Log4j 1.3 will obviously contain hard-coded rules to enable it to
configure itself. The novelty will be in its capability to learn new
tricks. These new rules must be specified somewhere. The question is
where? Where are these rules specified? There are at least two
possibilities.
1) In the XML configuration file
Nothing fancy. This is just the straightforward application of existing
digester usage patterns. The down side is that these rules must be
repeated in each configuration file.
2) Within the component being configured.
The component being configured informs the digester about the
additional rules it needs. These rules are applied only while the
component is being processed (configured). They are removed just after
the processing of that particular component finishes.
This approach would require changes in the commons-digester
model. Instead of having a single set of rules, the set of rules would
be hierarchical. There would always be the global set of rules at the
top. One ore more child rule-sets (defined by the components) would be
added/removed according to interactions with the components. The
search for patterns would proceed from child to parent rule-sets.
This is perhaps an overkill for log4j but I think it could be useful
in more complicated scenarios.
--
Ceki
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
