[PATCH] add support for multiple evaluators in BufferingAppenderSkeletan

• Key: LOG4NET-108
• Type: Improvement
• Status: Open
• Priority: Minor
• Assignee: Nicko Cadell
• Reporter: Drew Schaeffer
• Component/s: Appenders, Core
• Affects Version/s: 1.2.10
• Fix Version/s: 1.2.11

Description

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.

Comments

[Drew Schaeffer]

build against subversion revision 489214

[Drew Schaeffer]

Typed collection of ITriggeringEventEvaluators.

This patch doesn't depend on LOG4NET-107 but with the addition of ExceptionEvaluators this patch is the next step.

[Drew Schaeffer]

configuration of multiple evaluators is supported by the standard Add methods on the BufferingAppenderSkeletan class. ie

AddEvaluator ( ITriggeringEventEvaluator )
AddLossyEvaluator ( ITriggeringEventEvaluator )

therefore the xml needed to configure these is the same as it was before

<evaluator ... />
<lossyEvaluator ... />

[Ron Grabowski]

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?

[Nicko Cadell]

It would be possible to implement this feature without modifying the BufferingAppenderSkeleton but rather by building another ITriggeringEventEvaluator that holds a collection of child evaluators.
This is in some ways more flexible because it can be used everywhere a ITriggeringEventEvaluator is allowed.

If the implementation is added directly to the BufferingAppenderSkeleton then what strategy should be employed in deciding when to _trigger_. Any evaluator / all evaluators / or a combination? Once this is embedded in the BufferingAppenderSkeleton this would be hard to change, and someone will come up with a convincing argument as to why the implemented strategy is not appropriate for them.

If the strategy is delegated to the implementation of the ITriggeringEventEvaluator then this becomes much more extensible. An ITriggeringEventEvaluator can be written by anyone and deployed in any DLL not just in the log4net DLL.

[Ron Grabowski]

I think what Drew was getting at is that he wants Filters and Evaluators to behave similiar (i.e. allow multiple Evaluators to be added the same way that multiple Filters are added).

BufferingAppenderSkeleton could be changed to hold a linked list of Evaluators similiar to how AppenderSkeleton holds a linked list of Filters.