Allow configuration-based filtering rules to be diffrent for e-mail and log

[GoogleCodeExporter]

What new or enhanced feature are you proposing?

Provide a web.config method of applying filters to emails only and not log 
files.

What goal would this enhancement help you achieve?

There are some errors that do not require an action (e.g. 404) however it 
would be nice to continue to log them, without filling my inbox with 
emails.

I can't use the Global.asax method as this is a 3rd party web application, 
and we are "Not Allowed" to edit the supplied files.

Original issue reported on code.google.com by robert.s...@gmail.com on 19 May 2009 at 10:22

[GoogleCodeExporter]

Attached is a patch to implement my request - as I took a quick look at the 
source 
code and could see a way to implement it.

Basicly - each Log Module passes a module name to the filter Module (as part of 
event args).

in the config file replace the <test> node with a node for each module that 
requires 
filtering 

The filter module reads the rules from the config node with the name matching 
the 
module name (errorLog,errorMail,errorTweet).

Extra features - 1. the <test> node if it exists will be used as a default - 
backwards compatibility [no change in config = no change in behaviour.]

Extra features - 2. a <all> node if it exists will be Logicly Or'd with the 
specific 
node if it exists - allowing filters to be defind for the whole install with 
out 
repeating them.

(this is my first patch for this project let me know if you need anything done 
diffrently)  

cheers

Original comment by robert.s...@gmail.com on 19 May 2009 at 1:26

Attachments:

• filterModules.patch

[GoogleCodeExporter]

Original comment by azizatif on 19 May 2009 at 2:59

• Changed title: Allow configuration-based filtering rules to be diffrent for e-mail and log
• Changed state: Accepted
• Added labels: Component-Filter

[GoogleCodeExporter]

Original comment by azizatif on 27 May 2009 at 12:57

• Added labels: DotNet-All, Milestone-Release1.1

[GoogleCodeExporter]

Original comment by azizatif on 27 May 2009 at 1:50

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Implemented in r593.

There are now three new properties available for filtering:

- FilterSource
- FilterSourceType
- FilterSourceAssemblyName

The FilterSource property is the object requesting filtering. FilterSourceType 
and
FilterSourceAssemblyName are just helpers that return the type and assembly 
name of
FilterSource object. You can now filter based on source using, for example, the 
regex
assertion like this:

<regex binding="FilterSourceType.Name" pattern="mail" />

When the mailing module from ELMAH is filtering, FilterSource will be an 
instance of
Elmah.ErrorMailModule. The above assertion will get the type name (irrespective 
of
namespace) and filter the error if it contains "mail". When the logging module 
from
ELMAH is filtering, FilterSource will be an instance of Elmah.ErrorLogModule 
and the
assertion will let the error pass through and get logged.

Original comment by azizatif on 27 May 2009 at 2:19

[GoogleCodeExporter]

@robert.stocks: Thanks for your patch. It wasn't used directly though it was 
the seed
for another idea (documented above) and which is how the problem was eventually
solved. Adding the three properties seemed like the simplest way to get the 
effect
without affecting too many components. The change could be isolated to
ErrorFilterModule.cs.

Original comment by azizatif on 27 May 2009 at 2:21