As Patrick mentioned, the code to implement this is really trivial with getters
and setters. The whole point behind trying to have this TriggerLevel is,
currently the TriggeringEventEvaluator does nothing other than comparing the
logging event level with some threshold (currently ERROR). Users are definitely
allowed to configure their own TriggeringEventEvaluator to override the default
behaviour. However, i believe (just my personal opinion), instead of asking
users to *specify a class* for overriding the default behaviour it definitely
makes sense to ask them to configure the TriggerLevel (or whatever you may want
to call that) and let Log4j internally handle the the logic.
regards,
-Jaikiran
- Original Message
From: Wyss Patrick [EMAIL PROTECTED]
To: Log4J Users List log4j-user@logging.apache.org
Sent: Thursday, 5 July, 2007 6:37:47 PM
Subject: AW: SMTPAppender ignores Threshold value
certainly it is true that the code for your own TriggeringEventEvaluator is
trivial. however my personal opinion is that being able to set the triggering
level is a requirement which is common enough to be implemented in the
SMTPAppender. e.g. setting it to FATAL because you only want to know when your
app needs a restart seems quite common to me.
however the patch (which i implemented for me when SMTPAppender was not yet
able to authenticate) is even more trivial it's 12 lines of code (setter and
getter plus *one* line of code that changes in the DefaultEvaluator) so i guess
it would be reasonable to include it.
best reagrds
patrick
Reasonable? While you make a good point about the seeming
arbitrariness
of the default trigger, it really is pretty trivial code. In
my case,
and I suspect many others, the desirable trigger for sending
out recent
e-mail logs would be something entirely separate from log
level. --Wayne
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/