Max,
Thank you for bug report and related discussion. The
SMTPAppender.append method is called by
AppenderSkeleton.doAppend method which has the
if(closed) check. Your additional check is not
necesserary.
Regarding appender=null. I don't see the point of
setting a method parameter to null. Unless I am
missing an important point in which case I apologize,
your logic is flawed. Please supply a small program
to illustrate the bug you have identified as I don't
see a bug. Regards, Ceki
--- Max Stolyarov <[EMAIL PROTECTED]> wrote:
> 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
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
