DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24803>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24803 LevelMatchFilter not working as expected ------- Additional Comments From [EMAIL PROTECTED] 2003-11-19 16:42 ------- Eric, I reread the LevelMatchFilter javadoc and what they developed was logically correct but the problem I have is that the name of the filter does not make sense to me. This class should really be renamed to something clearer. The name of the class does not correctly describe its functionality because it will accept the logging of messages if there is no match. This makes absolutely no sense to me because of the name of the filter. I have come to an understanding of why this filter was created this way. It was designed this way to allow someone to define multiple filters for logging. We can add LevelMatchFilter for INFO, WARN, and FATAL. We would then expect to log only messages with these different levels. The way that the AppenderSkeleton class processes these filters is upon receiving a single DENY result it will not log the message. It will log the message if it continues to see only NEUTRAL results or a single ACCEPT result. Here is the code within the AppenderSkeleton class: Filter f = this.headFilter; FILTER_LOOP: while(f != null) { switch(f.decide(event)) { case Filter.DENY: return; case Filter.ACCEPT: break FILTER_LOOP; case Filter.NEUTRAL: f = f.next; } } this.append(event); The other interesting point that I wanted to make about this Appender has to do with the threshold. If the Appender threshold is less than or equal to the message level. It will be compared to the Appender filters. Since INFO is basically the lowest level besides ALL. These messages will always be compared to the Appender filter. I then wonder why the filter check was done this way. It seems to me that it does not perform what is expected. I understand why they do not want to append a message that a filter return DENY but shouldn't it also consider continuing to check that the other filters don't return an ACCEPT result? I would then consider changing the while to do the following: boolean isDenied = false; boolean isAccepted = false; Filter f = this.headFilter; while(f != null) { switch(f.decide(event)) { case Filter.DENY: isDenied = true; break; case Filter.ACCEPT: isAccepted = true; break; case Filter.NEUTRAL: break; } f = f.next; } // Only refuse events that have been denied and never accepted. if( isDenied && ! isAccepted ) return; this.append(event); Again, this is something that the log4j developers need to consider. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
