[
https://issues.apache.org/jira/browse/LOG4NET-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472479
]
Nicko Cadell commented on LOG4NET-108:
--------------------------------------
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.
> [PATCH] add support for multiple evaluators in BufferingAppenderSkeletan
> ------------------------------------------------------------------------
>
> Key: LOG4NET-108
> URL: https://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.
-
You can reply to this email to add a comment to the issue online.
