Hi Ceki,
Thanks for your reply.
Sorry... that was a bit misunderstanding on my part.
So, triggering is to trigger the action of "Sending email". And the condition
on which it is triggered in SMTPAppender is when it receives ERROR or FATAL
events (ie., as per DefaultEvaluator implementation). Is this right?
May be the documentation on SMTPAppender should explicitly mention that
reaction to triggering is sending mail... and that it will keep buffering the
messages otherwise.
Infact, any implementation of TriggeringEventEvaluator should clearly
document both TRUE and FALSE behaviour as a standard documentation.
Thanks & Regards,
nagu.
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 15, 2001 7:08 PM
To: LOG4J Developers Mailing List
Subject: Re: FW: TriggeringEventEvaluator: Is this needed in
SMTPAppender?
Nagarajan,
Sorry for not replying earlier. The TriggeringEventEvaluator does not filter
events at all. In particular, even whne the evaluator returns false, the
logging event is added to the SMTPappender's buffer.
You ask, "should I drop this logging event" to a filter but "should this
event trigger an email" to a TriggeringEventEvaluator. They are different
questions. Hope this answers the question. Ceki
At 18:23 15.03.2001 +0530, Nagarajan Chinnasamy wrote:
>Resending as it may not have reached the list...
>
>> -----Original Message-----
>> From: Nagarajan Chinnasamy
>> Sent: Tuesday, March 13, 2001 6:27 PM
>> To: '[EMAIL PROTECTED]'
>> Subject: TriggeringEventEvaluator: Is this needed in SMTPAppender?
>>
>> Hello ALL,
>>
>> Just a thought/question on the need for TriggeringEventEvaluator
>> used in SMTPAppender.
>>
>> If I understood right, all that TriggeringEventEvaluator does is to
>> evaluate a logging event to decide whether to send the event as
>> a mail or not. So, what basically it does is filtering.
>>
>> If so, why do we need this special usage? We already have Filters
>> that can be configured for appenders.
>>
>> Infact, from the source code, I understand that the default evaluator
>> is nothing but a priority filter that filters out the messages with
>> priority
>> less than ERROR. I am reproducing the code here:
>>
>> class DefaultEvaluator implements TriggeringEventEvaluator {
>> /**
>> Is this <code>event</code> the e-mail triggering event?
>>
>> <p>This method returns <code>true</code>, if the event priority
>> has ERROR priority or higher. Otherwisem it returns
>> <code>false</code>. */
>> public
>> boolean isTriggeringEvent(LoggingEvent event) {
>> return event.priority.isGreaterOrEqual(Priority.ERROR);
>> }
>> }
>>
>> Isn't it a good idea to leave it to work under the usual framework of
>> having
>> filters do this job rather than having special evaluators???
>>
>> I am looking at: jakarta-log4j-1.0.4
>>
>> Regards,
>> nagu.
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: [EMAIL PROTECTED] (preferred)
CH-1005 Lausanne [EMAIL PROTECTED]
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
