You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by Roman Fiedler <ro...@arcsmed.at> on 2006/12/14 15:01:10 UTC

log4j property file handling

Dear developers,

Questions+proposal:

Trying to optimise the SMTPAppender I found that it uses a trigger event 
evaluator. The properties may only contain the class name of the 
evaluator, the appender then creates an instance of this class and uses 
it. To have evaluators for diffrerent levels, you have to implement one 
for every level.

Questions: It seems to me that the only reason for this design is that 
appenders cannot be configured with complex objects, just ints, String, 
Level, is that correct? Would these change in the OptionConverter.java 
make sense for other users?

Proposal: If a configurable object (e.g. appender) contains a property x 
then and only a line

[appender].x=[String]

exists then the OptionConverter tries to convert the string to the type 
(for primitive types), otherwise it gets the class of the property and 
tries to create a new instance using a string only constructor. This 
will make most of  the simple properties work (e.g. int, long) but also 
Level, or BigInteger.

For more complex properties following scheme could be used:

[appender].x=[classname]
[appender].x.[subprop]=value

With this code, no special handling of e.g. layouts neccessary. When 
doing this recursively one could set most of even complex properties.

Goal: following initialisation should be possible:

log4j.appender.SMTPAppender.TriggerEvaluator=test.LevelEvaluator
log4j.appender.SMTPAppender.TriggerEvaluator.Level=Error
log4j.appender.SMTPAppender.TriggerEvaluator.MaxInvocationsPerHour=4
....


Would such a change make sense? Could xml-based log4j.properties also 
support such structures? Would log4j take them in their source archive 
or should I develop them als proprietary extension?

Comments appreciated!

roman