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
