LogWriter.ShouldLog

Topics: Logging Application Block
Nov 21, 2012 at 10:45 AM

Hi,

I have tested LogWriter.ShouldLog. It returns true even if I set tracingEnabled to false or try to log to a nonexisting category or set a severity filter.

Experiment 1:

-- Define category "General".

-- Set tracingEnabled="false" at <loggingConfiguration> level.

-- Log towards "General" category.

-- Call Microsoft.Practices.EnterpriseLibrary.Logging.Logger.ShouldLog for the LogEntry.

Result 1:

-- The log entry is logged.

-- ShouldLog returns true.

-- It's like tracingEnabled has no effect on logging.

Experiment 2:

-- Define category "General".

-- Log towards "Unknown" category.

-- Call Microsoft.Practices.EnterpriseLibrary.Logging.Logger.ShouldLog for the LogEntry.

Result 2:

-- The log entry is not logged.

-- ShouldLog returns true.

-- It's like ShouldLog does not take into account the category of the log entry.

Experiment 3:

-- Define category "General" with swithValue="Error".

-- Log towards "General" category with an "Information" severity.

-- Call Microsoft.Practices.EnterpriseLibrary.Logging.Logger.ShouldLog for the LogEntry.

Result 3:

-- The log entry is not logged.

-- ShouldLog returns true.

-- It's like ShouldLog does not take into account the severity of the log entry.

Based on these results, does anyone know what ShouldLog really checks?

The general structure of my logging configuration is as follows:

<loggingConfiguration name="" tracingEnabled="true" defaultCategory="General">
<listeners>
<add name="Flat File Trace Listener" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
fileName="C:\trace.log" formatter="Text Formatter" />
</listeners>
<formatters>
<add type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
template="Timestamp: {timestamp}{newline} Message: {message}{newline} Category: {category}{newline} Priority: {priority}{newline} EventId: {eventid}{newline} Severity: {severity}{newline} Title:{title}{newline} Machine: {localMachine}{newline} App Domain: {localAppDomain}{newline} ProcessId: {localProcessId}{newline} Process Name: {localProcessName}{newline} Thread Name: {threadName}{newline} Win32 ThreadId:{win32ThreadId}{newline} Extended Properties: {dictionary({key} - {value}{newline})}"
name="Text Formatter" />
</formatters>
<categorySources>
<add switchValue="All" name="General">
<listeners>
<add name="Flat File Trace Listener" />
</listeners>
</add>
</categorySources>
<specialSources>
<allEvents switchValue="Off" name="All Events" />
<notProcessed switchValue="Off" name="Unprocessed Category" />
<errors switchValue="Off" name="Logging Errors & Warnings" />
</specialSources>
</loggingConfiguration>

Thank you very much.

Regards.

Nov 21, 2012 at 3:56 PM

Hi,

I've found that ShouldLog is influenced only by logging filters, which is an orthogonal hierarchy of objects.

With the category logging filter, you can express a white list or a black list and add categories to it.

ShouldLog does not search the actual listener list to see if there is a listener that will deal with the log entry.

I guess that to influence ShouldLog based on the severity of the log entry, a custom log filter must be created.

I wanted to use ShouldLog to prefilter thorough debug traces when not active, so that they don't affect the normal perfomance of a high load server, but I've finally realized that it is not the best way to do it.

 

Regards.

Nov 22, 2012 at 5:40 AM

Yes, ShouldLog doesn't seem to 100% accurate.  I'm not sure if this is by design or a defect.  Enterprise framework logging - ShouldLog not working with SourceLevel filter is a similar issue.

--
Randy Levy
Enterprise Library support engineer
entlib.support@live.com