Appropriate use of log filters?

Topics: Exception Handling Application Block, Logging Application Block
Mar 9, 2007 at 11:28 PM
Using EntLib 2.0, I would like to be able to prompt the user before sending a log entry by email using a dialog box similar to the one provided by Windows Error Reporting (the log entry is created by an exception handler in the Exception Handling Block). Conceptually speaking, the decision "to log or not log" is what a filter does, so I implemented the dialog-raising in a custom filter. However, I obviously don't want the user to be prompted any time any entry is to be logged, only those that will end up being logged by an Email Trace Listener. As I understand it, all filters will always be applied (unless a filter higher up the chain returns false). So what I'm doing is creating a "categories" custom attribute for the filter. The filter's Filter method checks the categories of the LogEntry against this attribute to decide whether to raise the dialog.

Does this sound like a reasonable application of a custom log filter, or is there a more straightforward way, either in the current or the upcoming release of the Enterprise Library?
Mar 10, 2007 at 12:37 AM
It sounds like it would work, however the filter would be very tightly coupled with your particular context, and wouldn't work in situations where the categories or their TraceListeners were different to what you expect. It may make more sense to encapsulate this logic in a dervied TraceListener, eg UserPromptingEmailTraceListener, as this will work regardless of which categories you are using.

Mar 10, 2007 at 1:17 AM
Yes, you're probably right. I was avoiding that because I didn't want to duplicate the email-sending functionality & attributes of EmailTraceListener. Without rolling my own version of the Logging application block, would it be possible to derive UserPromptingEmailTraceListener from EmailTraceListener instead of CustomTraceListener and have it be recognized by the configuration tool?
Mar 10, 2007 at 1:48 AM
You won't need to roll your own block. You could probably derive from the EmailTraceListener and reuse its current data class, but you'd probably need to add your own designtime node class and registration commands.

A simpler option may be to modify the code for the EmailTraceListener and its Data (runtime config) and Node (designtime config) to add an extra PromptUser property. This will obviously require changes to EntLib code but will probably eliminate the need to create any new assemblies or classes.