Ceki,
Thanks for responding to my e-mail. I did some more checking and I think
that AppenderAttachableImpl class and SMPTAppender class both share the
blame for what was happening. Below is the code that I modified for the
SMPTAppender class's append() method and checkEntryConditions() method:
/**
Perform SMTPAppender specific appending actions, mainly adding
the event to a cyclic buffer and checking if the event triggers
an e-mail to be sent. */
public
void append(LoggingEvent event) {
// MAX: Modified checkEntryCondition() method to return false if this
// appender is closed
if(!checkEntryConditions()) {
return;
}
event.getThreadName();
event.getNDC();
if(locationInfo) {
event.setLocationInformation();
}
cb.add(event);
if(evaluator.isTriggeringEvent(event)) {
sendBuffer();
}
}
/**
This method determines if there is a sense in attempting to append.
<p>It checks whether there is a set output target and also if
there is a set layout. If these checks fail, then the boolean
value <code>false</code> is returned. */
protected
boolean checkEntryConditions() {
// MAX: Added to prevent events from being send if this appender was
// closed
if(this.closed)
return false;
if(this.msg == null) {
errorHandler.error("Message object not configured.");
return false;
}
if(this.evaluator == null) {
errorHandler.error("No TriggeringEventEvaluator is set for appender
["+
name+"].");
return false;
}
The original code for checkEntryConditions() did not check whether or not
the appender in question was closed or not and therefore did not return
false in the case when the appender was closed; I added this check. Also,
the append() method never properly acted to the condition when
checkEntryConditions() returned false. The original code simple displayed
the message, but never terminated the call to this method by returning from
it; I also added this condition.
Finally, appending message to any appender that was closed and removed from
the Appender Vector should also fail because the appender should no longer
exist. But what I found was that in the code of
<AppenderAttachableImpl.java>
public
void removeAppender(Appender appender) {
if(appender == null || appenderList == null)
return;
appenderList.removeElement(appender);
// MAX: When appender is removed from the appenderList, it is just
removed
// from the Vector, but is not dereferenced. We will dereference it by
// setting it to null
appender=null;
}
appender that was removed from appenderList was never dereferences, it was
never set to NULL. Therefore, if application already had a reference to this
appender, it did not matter if it was removed from the list when it came to
sending and processing events; messages were still send when appender was
closed and removed from the appender list. So, what I did I set appender
that was just removed to NULL (this also can be done inside the
removeElement(appender) method called just above my statement). When I did
that I was no longer able to send events using appender that was removed by
closing.
On the other hand, Ceki, can you please tell me if my logic was correct or
if I should have done anything different to resolve the problem. If you feel
that I did things properly, can you please tell me what do I need to do to
submit this as a bug so it can be modified for others in future releases of
log4j. Thanks
Max
-----Original Message-----
From: Ceki Gulcu [mailto:[EMAIL PROTECTED]]
Sent: Saturday, December 01, 2001 4:30 AM
To: Log4J Developers List
Subject: Re: For Ceki: Problem working with SMTPAppender
Max,
Any appender extending AppenderSkeleton will refuse to log after its close
method is called. SMTPAppender falls into this case. In any case, you should
remove the appender that was closed. Are you absolutely sure that the close
method of SMTPAppender was called? I suggest you insert a System.out.println
in SMTPAppender.close to make sure it is called on the right appender.
By the way, what were the modifications that solved the problem?
With regards to the new version of log4j, I don't think upgrading to log4j
1.2 will not solve the SMTPAppender issue. On the other hand, unless you
extended the Category class, you can consider version 1.2 as a drop in
replacement for 1.1.3. Just try it...
Regards, Ceki
At 17:27 30.11.2001 -0600, you wrote:
>Hi Ceki,
>
> After reading number of messages on this developer forum, I can see that
>you are the person who may be able to help me. In my application I am using
>SMTPAppender to send log events to my e-mail address when something
happens.
>I use management interface to create and remove SMTPAppenders, based on
>their name and other parameters, such as filter specifications. What I
>resently noticed was that if I remove SMTPAppender try to generate dummy
>alerts, I am still receiving e-mail messages. It seems like SMTPAppender is
>still active after I explicetly closed it. Also, if I would create another
>appender with the same name and try to generate more log events, I now
>receive two e-mails for each log event generate.
>
>In trying to resolve this problem I went and modified SMTPAppender class
and
>AppenderAttachableImpl class. After I did this, everything started to work
>fine.
>
>So, my question to you is:
>If you worked with SMTP appender before, did you ever noticed this
behavior?
>
>And if did, is this a bug or just a misexecution on my part?
>If this is a bug and you know about it, was it fixed in the latest release
>of log4j?
>
>Sorry for asking so many questions, but our application is very much
>integrated with log4j and I would not want to upgrade to a new release of
>log4j in the next month if I don't have to, but I also don't want to
support
>my custom version of log4j without a need for it. Thanks in advance.
>
>
>Max Stolyarov
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
