That makes sense. I didn't think of it from a code maintenance standpoint and the linked list is a much cleaner approach.
Is it worth creating an EvaluatorSkeleton to implement the Next property? With only two implementations of ITriggeringEventEvaluator this may be overkill but if there are more in the future this may be worth while. -----Original Message----- From: Ron Grabowski [mailto:[EMAIL PROTECTED] Sent: Thu 12/21/2006 11:33 PM To: Log4NET Dev Subject: Re: [jira] Commented: (LOG4NET-108) [PATCH] add support for multiple evaluators in BufferingAppenderSkeletan The AppenderSkeleton.FilterEvent method is pretty much self-contained and does the filtering in about 20 lines of code. Just the EvaluatorCollection class itself is many times that size plus is introduces related classes. Have you ever had a need to attach more than 4 or 5 evaluators to an appender? To make ITriggerEventEvaluator follow the IFilter pattern we'd need to add a Next property to the interface. It would probably be a good idea to make ITriggerEventEvaluator extend IOptionHandler so ActivateOptions is available too. ----- Original Message ---- From: Andrew Schaeffer <[EMAIL PROTECTED]> To: Log4NET Dev <[email protected]> Sent: Thursday, December 21, 2006 10:49:28 AM Subject: RE: [jira] Commented: (LOG4NET-108) [PATCH] add support for multiple evaluators in BufferingAppenderSkeletan I chose do use an EvaluatorCollection because order does not matter. With a Filter the order is obviously important and a linked list is the ideal solution. When an evaluator causes a flush the buffer is sent and the remaining evaluators do not get a chance to process the LoggingEvent. However, a linked list would work just as well and would be consistent with the implementation of filters. What is the best solution? -----Original Message----- From: Ron Grabowski (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wed 12/20/2006 11:15 PM To: [email protected] Subject: [jira] Commented: (LOG4NET-108) [PATCH] add support for multiple evaluators in BufferingAppenderSkeletan [ http://issues.apache.org/jira/browse/LOG4NET-108?page=comments#action_12460137 ] Ron Grabowski commented on LOG4NET-108: --------------------------------------- Why did you choose to use an EvaluatorCollection instead of a linked list similiar to how IFilters are processed on the AppenderSkeleton? If the EvaluatorCollection has 5 items in it and the 1st item causes a flush do the remaining 4 items still get a chance to process the LoggingEvent? > [PATCH] add support for multiple evaluators in BufferingAppenderSkeletan > ------------------------------------------------------------------------ > > Key: LOG4NET-108 > URL: http://issues.apache.org/jira/browse/LOG4NET-108 > Project: Log4net > Issue Type: Improvement > Components: Appenders, Core > Reporter: Drew Schaeffer > Priority: Minor > Attachments: EvaluatorCollection.cs, patch-file.diff > > > Currently BufferedAppenders only have support for one evaluator and one lossy > evaluator. This is fine when the only available evaluator is LevelEvaluator > (as multriple LevelEvaluators do not make sense) but with the addition of > ExceptionEvaluator (LOG4NET-107) it would be nice for > BufferingAppenderSkeletan to have a collection of evaluators. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
<<winmail.dat>>
