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
package com.cannon.log4j;
import org.apache.log4j.Level;
import org.apache.log4j.spi.LoggingEvent;
import org.apache.log4j.spi.TriggeringEventEvaluator;
public class TestEvaluator implements TriggeringEventEvaluator
{
private static final String triggerString = "MY TRIGGER STRING";
private static final Level triggerLevel = Level.INFO;
public boolean isTriggeringEvent(LoggingEvent logEvent)
{
boolean result = false;
String message = logEvent.getMessage().toString();
Level level = logEvent.getLevel();
if (level.isGreaterOrEqual(triggerLevel))
{
result = true;
}
else if (message.toUpperCase().startsWith(triggerString))
{
result = true;
}
return result;
}
}
jaikiran pai wrote:
Curt thanks for the response. I understand that the INFO and lesser level logs
are maintained in a
buffer till and ERROR event occurs (maybe for efficiency?). There might be valid
scenarios when the users might want to receive the mail as soon as the INFO event occurs
and not wait till some ERROR event is logged (which in some applications might never be
logged). Currently, in such cases where the user needs to override this behaviour, he
needs to provide his own implementation for the TriggeringEventEvaluator, which does not
seem reasonable. An alternate approach would be to allow the user to configure the
"TriggerLevel" in the configuration file instead of hardcoding this to ERROR in
the DefaultEvaluator. This would ensure that the user has the flexibility to configure
this.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
